From nobody Mon May 1 09:17: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 4DA461294F8 for ; Mon, 1 May 2017 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MBx9aCJYu8ZC for ; Mon, 1 May 2017 09:17:20 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 36B2812D0C3 for ; Mon, 1 May 2017 09:15:10 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id v14so76368234pfd.2 for ; Mon, 01 May 2017 09:15:10 -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=oUJ6hWxRNSfmk+2dZRywanYQW7Yuju8TzcMdP6X57mg=; b=ALnuv9/4ctYMym2yzZxQZF4AhLVElrP4+WwwuTIJfSv2+a4JZCkyLXA0fN5/gnXhMj 4ocaSpZjsLRLEta5ic4H85/r7EcIOKXNs+eYP3GNC/6y2vxI8Sr1IwisrWVhpLlL/Isb Dk4A9aD0o5qZuq9nJnzoR2ab0TpThYbLX6qQ0= 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=oUJ6hWxRNSfmk+2dZRywanYQW7Yuju8TzcMdP6X57mg=; b=M5KfUxal4f6ofJ3Mu9TAjzjqaHfZwnDivTl/Si8R1/xWVqGKZK4AI+dNKYog/eNmYC HGM1jkyfZzcVyqs+1dAV+K6aXJJ5Rur5Fzi5cdZBUay4tU5JmT1HQBZ2C4/MO5NFiiWq avpXCwfv4U5OLHPzkWlYA1nz11bpD4kUS0Hslxwdjadvu7MMZAIlgQFkzrtgOq3U/Sxr iqOkETBoepbaKjLH/rEuAdD3J7USZbzIlB+9CG6nmOs+/SMqQxdcvdtDki4WNrOP0MIq d32yG4+lC1onU6fYBVbxf3g7Vx5NIflAEFJh8NpsEI5Zb/dz5ksESILbqY8djLty/pOe kl/w== X-Gm-Message-State: AN3rC/6XXRVNF/ssAVecq389mkxjlAoRmnW0XRjQZTGleNTcCzuYTLV4 Wpwk+CiG65SA1eSu0hLtpx+g+1a3376o X-Received: by 10.84.142.133 with SMTP id 5mr35249297plx.52.1493655309728; Mon, 01 May 2017 09:15:09 -0700 (PDT) MIME-Version: 1.0 References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> In-Reply-To: From: David Benjamin Date: Mon, 01 May 2017 16:14:58 +0000 Message-ID: To: Brian Smith , Jim Schaad Cc: curdle Content-Type: multipart/alternative; boundary=94eb2c11ac2a278ace054e78bac7 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: Mon, 01 May 2017 16:17:22 -0000 --94eb2c11ac2a278ace054e78bac7 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 30, 2017 at 8:17 PM Brian Smith wrote: > Jim Schaad wrote: > > It is not always possible to detect corruption when you store in an > unencrypted form. > > What kind of corruption would we not be able to detect? It is possible > that somehow the private key could get corrupted and that there could > be a corresponding corruption to the public key such that they match > again, but this seems extremely unlikely unless somebody simply > replaced the key pair with another key pair. > > > It would also not be possible to know if it was the private key or the > public key that has been corrupted, just that the two values do not match. > > This is the case with any kind of cryptographic check, including HMAC > or whatnot. > (Not that it matters, but, to that end, would detecting corruption not be just as easily served by stashing a checksum somewhere? If not external to the serialization, there is already that attributes field.) > > > However, unless this is documented in the draft one way or > > another as a MUST accept or a MUST NOT generate, I think > > it will be an interop nightmare. In particular, we should avoid > > the situation where some implementations produce v2 keys > > so they can add the publicKey field, and where other > > implementations reject v2 keys because they only parse v1, > > where the publicKey field isn't allowed. > > > > I have not heard that this is an issue today with DH keys. This > > makes me think that this is not going to be a big issue. I expect > > that most implementations would all for parsing v2 keys even if > > they then ignore the public key field. > > If that's the expectation then let's enshrine that in the spec by > saying that implementations MUST accept v2 keys for these types of > keys. > > In particular, I have seen PKCS#8 implementations that reject any v2 > PKCS#8 file instead of ignoring the extra fields. > As the author of one such PKCS#8 implementation, I'd simply missed that v2 PKCS#8 existed. Happy to add support (by way of ignoring the field probably, yeah). Lacking any useful text about what to do, I interpreted the version field to be analogous to RSAPrivateKey, another PKCS spec. There, an RFC 2437 implementation that attempted to be forwards-compatible (by accepting unknown versions and ignoring appended fields) would have been confused come RFC 3447, which decided v1 meant a semantically-incompatible otherPrimeInfos field. RFC 5958 continues this. It does use ASN.1 extension markers, but X.680 merely says "The action that is taken in each situation is determined by the ASN.1 specifier", and RFC 5958 does not appear to say anything. Is the intent that OneAsymmetricKey parsers accept a hypothetical v3 with further appended fields, or should they reject those to allow for RFC-3447-like changes? If so, how do they handle the version <=> extra field correspondence? A numerical comparison? Assume all unknown values are newer? The version number used in the ASN.1 tags corresponds to the symbolic name of the version constants, rather than the numerical value, so it's not obvious whether, say, defining v3(-1) would be acceptable. David --94eb2c11ac2a278ace054e78bac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 30= , 2017 at 8:17 PM Brian Smith <b= rian@briansmith.org> wrote:
= Jim Schaad <= ietf@augustcellars.com> wrote:
> It is not always possible to detect corruption when you store in an un= encrypted form.

What kind of corruption would we not be able to detect? It is possible
that somehow the private key could get corrupted and that there could
be a corresponding corruption to the public key such that they match
again, but this seems extremely unlikely unless somebody simply
replaced the key pair with another key pair.

> It would also not be possible to know if it was the private key or the= public key that has been corrupted, just that the two values do not match.=

This is the case with any kind of cryptographic check, including HMAC
or whatnot.

(Not that it matters, but, = to that end, would detecting corruption not be just as easily served by sta= shing a checksum somewhere? If not external to the serialization, there is = already that attributes field.)
=C2=A0
> > However, unless this is documented in the draft one way or
> another as a MUST accept or a MUST NOT generate, I think
> it will be an interop nightmare. In particular, we should avoid
> the situation where some implementations produce v2 keys
> so they can add the publicKey field, and where other
> implementations reject v2 keys because they only parse v1,
> where the publicKey field isn't allowed.
>
> I have not heard that this is an issue today with DH keys.=C2=A0 This<= br> > makes me think that this is not going to be a big issue.=C2=A0 I expec= t
> that most implementations would all for parsing v2 keys even if
> they then ignore the public key field.

If that's the expectation then let's enshrine that in the spec by saying that implementations MUST accept v2 keys for these types of
keys.

In particular, I have seen PKCS#8 implementations that reject any v2
PKCS#8 file instead of ignoring the extra fields.

=
As the author of one such PKCS#8 implementation, I'd simply = missed that v2 PKCS#8 existed. Happy to add support (by way of ignoring the= field probably, yeah). Lacking any useful text about what to do, I interpr= eted the version field to be analogous to RSAPrivateKey, another PKCS spec.= There, an RFC 2437 implementation that attempted to be forwards-compatible= (by accepting unknown versions and ignoring appended fields) would have be= en confused come RFC=C2=A03447, which decided v1 meant a semantically-incom= patible otherPrimeInfos field.

RFC 5958 conti= nues this. It does use ASN.1 extension markers, but X.680 merely says "= ;The action that is taken in each situation is determined by the ASN.1 spec= ifier", and RFC 5958 does not appear to say anything.
=
Is the intent that OneAsymmetricKey parsers accept a hypothe= tical v3 with further appended fields, or should they reject those to allow= for RFC-3447-like changes? If so, how do they handle the version <=3D&g= t; extra field correspondence? A numerical comparison? Assume all unknown v= alues are newer? The version number used in the ASN.1 tags corresponds to t= he symbolic name of the version constants, rather than the numerical value,= so it's not obvious whether, say, defining v3(-1) would be acceptable.=

David
--94eb2c11ac2a278ace054e78bac7-- From nobody Mon May 1 11:54: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 56C7912EAFA for ; Mon, 1 May 2017 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qlahe9uyDOiB for ; Mon, 1 May 2017 11:54:22 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFAF129431 for ; Mon, 1 May 2017 11:51:37 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k87so129177118ioi.0 for ; Mon, 01 May 2017 11:51:37 -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=SpPebGVQvFRP9VhAbFNwVhkg+DvPb2CtJZm9w74mfTg=; b=mnQMcU2IYAWet6fZhBCPSD0/FHbegr712/IhvoC/akw2QLzkPBLse1ihdmsDFB1FxZ NFQNvQwwOfuXMOAAQi22bIZTxPv4qxTZMy/xBqKrJTa5HUsiEi15PdnTCkMrnBx+h86W ZFJTQ9dq9yhqiQXmX4gJ9wm6r7s/GFmAZZfpBt4ObkxrMgVgLz0Q/uock5mPcCycyXWz mKH/DPiduN15hFqDE5EM33hbgUTQqvH0nNXdpL1+I8p3Z7KzBu3pFWZ6cUlIWtpIcmSz uBEBiIAkWQb7ds98we/ZWLyAueA+xX/5LowL2CPRkKmXU2rVMhOB1/GeCWThtp3quvI9 Tr0Q== 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=SpPebGVQvFRP9VhAbFNwVhkg+DvPb2CtJZm9w74mfTg=; b=oAYj+bb32O/Jhd+I8v2C8xbIgxHul9qcQtrW62/htjKvCYcf7GKy/Ax9LK5qgupOoQ PrH+/6Ix0Wa0cU3Him8bfOqPmkbOlRmbG1Ldzz8wN86YWnWmGpGw+t1tLbbJNRo+iCdC 2il6TsBy0UQtOEgndp8Avd63p74xNQSyBo8scOKDUKcEnIoAZFn4Gb5oBhv3+Wrwd1zd UATTgtbAtx2/VGGoX9nj9yWtKaOac81Psdaxy14ZTZSsXuzFVL7lrLaOxckYspPu5kd5 XsH7XJUYSBqbG4cSSSifarjS5mxijdJKs/AU/NZFl3M+1bglJN27jfXUZ5PAjFMxtB9O +MpA== X-Gm-Message-State: AN3rC/63Yl/EHG7N2rVfVLn0/v13jqyRWaIuWwp/P0ORPCBC7LOBqUeO pgwbBiFCLMOfmg6AJ+wWyMrrLpK59g== X-Received: by 10.107.12.22 with SMTP id w22mr23555557ioi.209.1493664696544; Mon, 01 May 2017 11:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Mon, 1 May 2017 11:51:36 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Mon, 1 May 2017 08:51:36 -1000 Message-ID: To: David Benjamin Cc: Jim Schaad , curdle Content-Type: text/plain; charset=UTF-8 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: Mon, 01 May 2017 18:54:24 -0000 David Benjamin wrote: > (Not that it matters, but, to that end, would detecting corruption not be > just as easily served by stashing a checksum somewhere? If not external to > the serialization, there is already that attributes field.) Yep, there would be many ways of doing it, but none standardized. > Is the intent that OneAsymmetricKey parsers accept a hypothetical v3 with > further appended fields, or should they reject those to allow for > RFC-3447-like changes? If so, how do they handle the version <=> extra field > correspondence? A numerical comparison? Assume all unknown values are newer? > The version number used in the ASN.1 tags corresponds to the symbolic name > of the version constants, rather than the numerical value, so it's not > obvious whether, say, defining v3(-1) would be acceptable. There are multiple problems with rfc5958 and its use of version field is one. Here is what I'm planning to do: For now, for RSAPrivateKey and ECPrivateKey, accept only PKCS#8 v1, since publicKey isn't necessary for them. Later I might accept PKCS#8 v2 for RSAPrivateKey and ECPrivateKey and verify that publicKey exactly matches the copy of the public key stored in privateKey. For key types specified in this draft, I will provide a flag where the user indicates whether they want to require the pairwise consistency check to pass. If the flag is "no consistent check needed" then I will accept v1 (with no publicKey). Otherwise if the flag is "consistency check needed" then I will only accept v2 where the publicKey field is present and consistent with the private key. Cheers, Brian -- https://briansmith.org/ From nobody Tue May 2 05:48:48 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 96DAA1316D9; Tue, 2 May 2017 05:48:42 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149372932250.9872.9605172450859269679@ietfa.amsl.com> Date: Tue, 02 May 2017 05:48:42 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-00.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, 02 May 2017 12:48:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-00.txt Pages : 9 Date : 2017-05-01 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-00 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 2 06:57: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 848D2128C82 for ; Tue, 2 May 2017 06:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gsGVrtTfx9Bz for ; Tue, 2 May 2017 06:57:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D551314A8 for ; Tue, 2 May 2017 06:54:23 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4F033106D18 for ; Tue, 2 May 2017 13:54:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4F033106D18 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 4F033106D18 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1D8BC78C29 for ; Tue, 2 May 2017 13:54:23 +0000 (UTC) From: Hubert Kario To: curdle@ietf.org Date: Tue, 02 May 2017 15:54:21 +0200 Message-ID: <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com> In-Reply-To: <149347252355.2923.13177496291079730679@ietfa.amsl.com> References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8843063.Guij1U4mDF"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 02 May 2017 13:54:23 +0000 (UTC) Archived-At: Subject: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:57:27 -0000 --nextPart8843063.Guij1U4mDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 29 April 2017 15:28:43 CEST 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. >=20 > Title : GSS-API Key Exchange with SHA2 > Authors : Simo Sorce > Hubert Kario > Filename : draft-ietf-curdle-gss-keyex-sha2-00.txt > Pages : 16 > Date : 2017-04-28 >=20 > Abstract: > This document specifies additions and amendments to SSH GSS-API > Methods [RFC4462]. It defines a new key exchange method that uses > SHA-2 for integrity and deprecates weak DH groups. The purpose of > this specification is to modernize the cryptographic primitives used > by GSS Key Exchanges. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-00 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-00 One of the nice properties of Kerberos, because it uses only symmetric=20 cryptography, is that it is secure against quantum computer attacks. Unfortunately, neither the previous gss-api kex scheme, nor the one we=20 proposed here (as it is essentially the same), maintain that property. This is because the input to the HASH function, with one exception, are=20 transferred in clear. That only secret input is the value calculated using= =20 algorithm vulnerable to quantum computers - FF or EC version of Diffie-Hell= man Thus my question are,=20 1). should we change the input provided to HASH to provide quantum computer= =20 resistance, or 2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes (and= =20 forget about QC-resistance - that's the current draft), or 3). should we multiply the kex options further and provide QC-resistant=20 variants of all the GSSAPI kex algorithms? As for technical details, I was thinking of adding a step in which the peer= s=20 each choose a random value, GSS_Wrap it, send it to peer, GSS_Unwrap peers= =20 value and append their value and the peers decrypted value to HASH input. =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 --nextPart8843063.Guij1U4mDF 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 iQIcBAABCgAGBQJZCI+NAAoJEJKo0bgB0vX1O5kQAIqCXcF7rTvpWJ3xYUtRM9Ag M2wIZjvjtXDY7jXhqLuWI1ytbcwFdMifmnmARDlHOHPbahc0uJp5OR5D4U2OUInO doeth7DZnuEmuKydArcNP4J3fsmzpIfYapgLNk1zefOlMFrrtVpKwTZkkGkmheyj +50yUrlnFgOxsRf6V1OmazSNVJteueJJllmR7T+W1PDUEPGYDTQNQyw/B2Qn+EBZ uJPpVjD/EDIjA2XYAU+aJeLgTjU/dO/GmtyIOv4D7kcC7VTmGs3yvqau+WZkWXPX Wi7ac3Yy+YiAUxKB2N+2ghpJCW6nMzHVwxDpjISKKIwzuw8AKUylI6te2NWJaMD6 VtEsFBwVjD3TeSqdZcznpQ2Y1P192D5c92ud9hOcpr2VKTeFZKouZ4oA/nFlf1Fc IHB5kNMsVJ/r5QcXX8+Xz8mb0EG9g2WV6ieUVdh9xLzOmUTA/pEyh8+Q6YUm8p3K l7pZyaY0RMspCCOEuiSU/vzEgcv/ASGjdDPxZ01jdZXrYZaf7gJftwud5snYJc4a UeDcEzxnuA4FZzUxyyyStWaP3zUj0/441Mw5wz7eoavKWNnX3KIUlkDRvUU6BC3U nj+YxETEDBMnRM0RumeF8M6h5s/Noiryq1YBbowJy2K812+K0WQu1yCEe5Q+h2nw x639rizwYUxQAFlD28kN =gs21 -----END PGP SIGNATURE----- --nextPart8843063.Guij1U4mDF-- From nobody Tue May 2 11:10: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 5281B129B5C for ; Tue, 2 May 2017 11:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 ax_3csX-RPMv for ; Tue, 2 May 2017 11:10:05 -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 3B6CF129B7E for ; Tue, 2 May 2017 11:07:03 -0700 (PDT) Received: from [78.128.48.21] (port=59826 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 1d5cCR-0039rt-Vl for curdle@ietf.org; Tue, 02 May 2017 21:06:59 +0300 Message-ID: <5908CAC4.2010705@roumenpetrov.info> Date: Tue, 02 May 2017 21:07:00 +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 References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: 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] WG status and extension negotiation 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, 02 May 2017 18:10:08 -0000 Hi, I would like to split my comments in two parts. First part is about extension negotiation (draft-ietf-curdle-ssh-ext-info-nn.txt) and subject of this email. I'm author of PKIX-SSH secure shell implementation that support X.509 certificate based publickey and hostbased algorithms. Goal is to find way transparently to users to switch from legacy algorithms to rfc6187 one. Legacy algorithms as defined in draft-ietf-secsh-transport-12.txt (31 Jan. 2002) are - x509v3-sign-rsa and - x509v3-sign-dss . Algorithms that correspond to same key type defined in rfc6187 are - x509v3-ssh-rsa and - x509v3-ssh-dss . Currently x509v3-rsa2048-sha256 ( rfc6187) is out of my scope. Daniel Migault wrote: > Hi, > > So far we have not received many inputs and I would like to make sure we > understand Romen's concern. My understanding of the concerned raised by > Romen is that specifying signature algorithms may complexity the ways > Public Key Algorithm registries are designated. However it looks to me one > reason is that we are moving from implicit signature scheme to explicit > ones. > > Romen please re-state your issues with the draft, clearly expose the issues > as well as the alternate you would fine acceptable. Let review be example following case - secure token (smart-card), RSA key and associated X.509 certificate. Which publickey algorithm to in public key authentication without to probe all listed below? - (1) x509v3-sign-rsa (legacy) - (2) x509v3-ssh-rsa (rfc6187) - (3) x509v3-rsa2048-sha256 (rfc6187 if applicable, perhaps will be implemented in PKIX-SSH) - (4) ssh-rsa (rfc4253) - (5) rsa-sha2-256 (upcoming) - (6) rsa-sha2-512 (upcoming) To find suitable algorithm we could use "software version" field (see rfc4253 4.2. Protocol Version Exchange). This solution is possible but requires up-to date database with information for vendor, version and supported ssh features. For such solution maintenance cost is too high. Another solution id peers to inform each other for supported functionality. So "extension negotiation mechanism"fail into this category. Denis, author of extension negotiation propose "server-sig-algs". Until now ssh related documents define publickey algorithm - see rfc4252, chapter 7. Public Key Authentication Method: "publickey") and hostbased (same rfc) and format of key and signature in with triplet : (I) public key algorithm name in USERAUTH_REQUEST message (rfc4252) (II) certificate or public key format identifier (rfc4253) (III) signature format identifier (as specified by the public key/certificate format) (rfc4253) For algorithms (1), (2) and (4) the triplet is : (1) x509v3-sign-rsa / --- (!?!) / x509v3-sign-rsa (2) x509v3-ssh-rsa / x509v3-ssh-rsa / ssh-rsa (4) ssh-rsa / ssh-rsa / ssh-rsa As is visible identifier of signature algorithm overlap two publickey algorithm. To avoid ambiguities in PKIX-SSH 10.1 I implement new extension (a) /"publickey-algorithms@roumenpetrov.info"/ . Thus PKIX-SSH could list all algorithms from above (3* if implemented) as "public key algorithm name" in unique. As of today client will chose algorithm (1) but in the near future (perhaps next version) rfc6187 algorithm(2) will be preferred chose. Extension (b) "server-sig-algs" is also announced by PKIX-SSH but with restriction - list only algorithms whose name match identifier of signature. This exclude automatically rfc6187 but could be used for compatibility with implementation like Bitvise and OpenSSH as they supports "algorithms whose name match identifier of signature". In connection to those servers PKIX-SSH will chose algorithm (5). In connection to server without extensions - client will try (1) and if not accepted (4). Above is part of PKIX-SSH feature called "/adaptive public key algorithm selection"/ - an automatic process. Manual configurations that impact /public key algorithm selection is out of scope to this mail ./ In conclusion : extension negotiation mechanism is valuable solution to resolve case above if propose an extension that allows in unique way to chose triplet for USERAUTH_REQUEST message. > Yours, > Daniel > [SNIP] Regards, Roumen Petrov From nobody Wed May 3 12:31:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59E129AF1 for ; Wed, 3 May 2017 12:31:42 -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 CM_IFvOAI5fp for ; Wed, 3 May 2017 12:31:34 -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 4EF0D129AEE for ; Wed, 3 May 2017 12:29:39 -0700 (PDT) Received: from [78.128.48.21] (port=45196 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 1d5zxw-001e1U-8a for curdle@ietf.org; Wed, 03 May 2017 22:29:36 +0300 Message-ID: <590A2FA0.3070601@roumenpetrov.info> Date: Wed, 03 May 2017 22:29:36 +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 References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020000000909070005050907" 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] WG status and rsa-sha2 as public key algorithm 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, 03 May 2017 19:31:43 -0000 This is a multi-part message in MIME format. --------------020000000909070005050907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel Migault wrote: > Hi, > > [snip] > Romen please re-state your issues with the draft, clearly expose the issues > as well as the alternate you would fine acceptable. I would like to propose an redaction over draft-ietf-curdle-rsa-sha2-03 (see attached file draft-ietf-curdle-rsa-sha2-03+rpetrov.txt). Attached file" draft-ietf-curdle-rsa-sha2-03+rpetrov.wdiff.html" shows modifications as word-diff in html format : - removed: red font, strikeout - added : green font I chose version 3 as this version is mostly fine with me except few substitutions(rewording) to follow style of previous SSH related documents - [RFC4253], [RFC5656] and [RFC6187] (see modifications in chapter 2 Public Key Algorithms). No modification in structure of messages, formats and etc. Using mostly word "Public Key Algorithm" will allow section(chapter) "4. IANA Considerations" to be written in very simple manner. The totally rewritten chapter adds references to [RFC4250] and [RFC4251] . Section "3. Discovery of signature algorithms supported by servers" in not updated yet (depends from another discussion). Regards, Roumen Petrov --------------020000000909070005050907 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-curdle-rsa-sha2-03+rpetrov.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-curdle-rsa-sha2-03+rpetrov.txt" DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBELiBCaWRlcg0KVXBkYXRlczogNDI1MiwgNDI1MyAoaWYgYXBwcm92 ZWQpICAgICAgICAgICAgICAgICAgICAgICAgQml0dmlzZSBMaW1pdGVkDQpJbnRlbmRlZCBz dGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkg MjcsIDIwMTcNCkV4cGlyZXM6IEF1Z3VzdCAyNywgMjAxNw0KDQoNCiAgICAgIFVzZSBvZiBS U0EgS2V5cyB3aXRoIFNIQS0yIDI1NiBhbmQgNTEyIGluIFNlY3VyZSBTaGVsbCAoU1NIKQ0K ICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtY3VyZGxlLXJzYS1zaGEyLTAzLnR4dA0K DQoNCkFic3RyYWN0DQoNCiAgVGhpcyBtZW1vIGRlZmluZXMgYW4gYWxnb3JpdGhtIG5hbWUs IHB1YmxpYyBrZXkgZm9ybWF0LCBhbmQgc2lnbmF0dXJlDQogIGZvcm1hdCBmb3IgdXNlIG9m IFJTQSBrZXlzIHdpdGggU0hBLTIgNTEyIGZvciBzZXJ2ZXIgYW5kIGNsaWVudA0KICBhdXRo ZW50aWNhdGlvbiBpbiBTU0ggY29ubmVjdGlvbnMuDQoNClN0YXR1cw0KDQogIFRoaXMgSW50 ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUN CiAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBU YXNrDQogIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBz LiAgTm90ZSB0aGF0IG90aGVyDQogIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtp bmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMN CiAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbA0KICBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1sDQogIA0KICBUaGUgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KQ29weXJpZ2h0DQoNCiAgQ29weXJp Z2h0IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlDQogIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWwNCiAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAoaHR0 cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRh dGUgb2YNCiAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzDQogIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJp Z2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICB0byB0aGlzIGRvY3VtZW50 LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0K ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA0LmUgb2YNCiAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZS4NCg0KDQoNCg0KQmlkZXIgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAg IEZlYnJ1YXJ5IDIwMTcNCg0KDQoxLiAgT3ZlcnZpZXcgYW5kIFJhdGlvbmFsZQ0KDQogIFNl Y3VyZSBTaGVsbCAoU1NIKSBpcyBhIGNvbW1vbiBwcm90b2NvbCBmb3Igc2VjdXJlIGNvbW11 bmljYXRpb24gb24NCiAgdGhlIEludGVybmV0LiBJbiBbUkZDNDI1M10sIFNTSCBvcmlnaW5h bGx5IGRlZmluZWQgdGhlIHNpZ25hdHVyZQ0KICBtZXRob2RzICJzc2gtcnNhIiBmb3Igc2Vy dmVyIGFuZCBjbGllbnQgYXV0aGVudGljYXRpb24gdXNpbmcgUlNBIHdpdGgNCiAgU0hBLTEs IGFuZCAic3NoLWRzcyIgdXNpbmcgMTAyNC1iaXQgRFNBIGFuZCBTSEEtMS4NCiAgIA0KICBB IGRlY2FkZSBsYXRlciwgdGhlc2Ugc2lnbmF0dXJlIG1ldGhvZHMgYXJlIGNvbnNpZGVyZWQg ZGVmaWNpZW50Lg0KICBGb3IgVVMgZ292ZXJubWVudCB1c2UsIE5JU1QgaGFzIGRpc2FsbG93 ZWQgMTAyNC1iaXQgUlNBIGFuZCBEU0EsIGFuZA0KICB1c2Ugb2YgU0hBLTEgZm9yIHNpZ25p bmcgWzgwMC0xMzFBXS4NCiAgIA0KICBUaGlzIG1lbW8gZGVmaW5lcyBhIG5ldyBhbGdvcml0 aG0gbmFtZSBhbGxvd2luZyBmb3IgaW50ZXJvcGVyYWJsZSB1c2UNCiAgb2YgUlNBIGtleXMg d2l0aCBTSEEtMiAyNTYgYW5kIFNIQS0yIDUxMiwgYW5kIGEgbWVjaGFuaXNtIGZvciBzZXJ2 ZXJzDQogIHRvIGluZm9ybSBTU0ggY2xpZW50cyBvZiBzaWduYXR1cmUgYWxnb3JpdGhtcyB0 aGV5IHN1cHBvcnQgYW5kIGFjY2VwdC4NCg0KMS4xLiAgUmVxdWlyZW1lbnRzIFRlcm1pbm9s b2d5DQoNCiAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIs ICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICBkb2N1bWVudCBh cmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KMi4g IFB1YmxpYyBLZXkgQWxnb3JpdGhtcw0KDQogIFRoaXMgbWVtbyBhZG9wdHMgdGhlIHN0eWxl IGFuZCBjb252ZW50aW9ucyBvZiBbUkZDNDI1M10gaW4gc3BlY2lmeWluZw0KICBob3cgdXNl IG9mIGEgcHVibGljIGtleSBhbGdvcml0aG0gaXMgaW5kaWNhdGVkIGluIFNTSC4NCg0KICBU aGUgZm9sbG93aW5nIG5ldyBwdWJsaWMga2V5IGFsZ29yaXRobXMgYXJlIGRlZmluZWQ6DQog ICANCiAgICByc2Etc2hhMi0yNTYgICAgUkVDT01NRU5ERUQgICAgc2lnbiAgICBSYXcgUlNB IGtleQ0KICAgIHJzYS1zaGEyLTUxMiAgICBPUFRJT05BTCAgICAgICBzaWduICAgIFJhdyBS U0Ega2V5DQoNCiAgVGhlc2UgYWxnb3JpdGhtcyBhcmUgc3VpdGFibGUgZm9yIHVzZSBib3Ro IGluIHRoZSBTU0ggdHJhbnNwb3J0DQogIGxheWVyIFtSRkM0MjUzXSBmb3Igc2VydmVyIGF1 dGhlbnRpY2F0aW9uLCBhbmQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uDQogIGxheWVyIFtSRkM0 MjUyXSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KDQoyLjEuICBQdWJsaWMgS2V5IEZv cm1hdA0KDQogIFNpbmNlIFJTQSBrZXlzIGFyZSBub3QgZGVwZW5kZW50IG9uIHRoZSBjaG9p Y2Ugb2YgaGFzaCBmdW5jdGlvbiwgYm90aA0KICBuZXcgYWxnb3JpdGhtcyByZXVzZSB0aGUg cHVibGljIGtleSBmb3JtYXQgb2YgdGhlIGV4aXN0aW5nICJzc2gtcnNhIg0KICBhbGdvcml0 aG0gYXMgZGVmaW5lZCBpbiBbUkZDNDI1M106DQoNCiAgICBzdHJpbmcgICAgInNzaC1yc2Ei DQogICAgbXBpbnQgICAgIGUNCiAgICBtcGludCAgICAgbg0KICAgICAgDQogIEFsbCBhc3Bl Y3RzIG9mIHRoZSAic3NoLXJzYSIgZm9ybWF0IGFyZSBrZXB0LCBpbmNsdWRpbmcgdGhlIGVu Y29kZWQNCiAgc3RyaW5nICJzc2gtcnNhIiwgaW4gb3JkZXIgdG8gYWxsb3cgdXNlcnMnIGV4 aXN0aW5nIFJTQSBrZXlzIHRvIGJlDQogIHVzZWQgd2l0aCB0aGUgbmV3IHNpZ25hdHVyZSBm b3JtYXRzLCB3aXRob3V0IHJlcXVpcmluZyByZS1lbmNvZGluZywNCiAgb3IgYWZmZWN0aW5n IGFscmVhZHkgdHJ1c3RlZCBrZXkgZmluZ2VycHJpbnRzLg0KICAgDQoyLjIuICBTaWduYXR1 cmUgRW5jb2RpbmcNCg0KICBTaWduaW5nIGFuZCB2ZXJpZnlpbmcgdXNpbmcgdGhlc2UgYWxn b3JpdGhtcyBpcyBwZXJmb3JtZWQgYWNjb3JkaW5nIHRvDQogIHRoZSBSU0FTU0EtUEtDUzEt djFfNSBzY2hlbWUgaW4gW1JGQzM0NDddIHVzaW5nIFNIQS0yIFtGSVBTLTE4MC00XSBhcw0K ICBoYXNoOyBNR0YxIGFzIG1hc2sgZnVuY3Rpb247IGFuZCBzYWx0IGxlbmd0aCBlcXVhbCB0 byBoYXNoIHNpemUuDQoNCg0KQmlkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTcNCiAgIA0KICANCiAgRm9yIHRoZSBhbGdvcml0aG0gInJzYS1zaGEyLTI1NiIsIHRo ZSBoYXNoIHVzZWQgaXMgU0hBLTIgMjU2Lg0KICBGb3IgdGhlIGFsZ29yaXRobSAicnNhLXNo YTItNTEyIiwgdGhlIGhhc2ggdXNlZCBpcyBTSEEtMiA1MTIuDQoNCiAgVGhlIHJlc3VsdGlu ZyBzaWduYXR1cmUgaXMgZW5jb2RlZCBhcyBmb2xsb3dzOg0KDQogICAgc3RyaW5nICAgICJy c2Etc2hhMi0yNTYiIC8gInJzYS1zaGEyLTUxMiINCiAgICBzdHJpbmcgICAgcnNhX3NpZ25h dHVyZV9ibG9iDQoNCiAgVGhlIHZhbHVlIGZvciAncnNhX3NpZ25hdHVyZV9ibG9iJyBpcyBl bmNvZGVkIGFzIGEgc3RyaW5nIGNvbnRhaW5pbmcNCiAgUyAtIGFuIG9jdGV0IHN0cmluZyB3 aGljaCBpcyB0aGUgb3V0cHV0IG9mIFJTQVNTQS1QS0NTMS12MV81LCBvZg0KICBsZW5ndGgg ZXF1YWwgdG8gdGhlIGxlbmd0aCBpbiBvY3RldHMgb2YgdGhlIFJTQSBtb2R1bHVzLg0KICAN CjIuMy4gIFVzZSBmb3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uDQoNCiAgVG8gZXhwcmVzcyBz dXBwb3J0IGFuZCBwcmVmZXJlbmNlIGZvciBvbmUgb3IgYm90aCBvZiB0aGVzZSBhbGdvcml0 aG1zDQogIGZvciBzZXJ2ZXIgYXV0aGVudGljYXRpb24sIHRoZSBTU0ggY2xpZW50IG9yIHNl cnZlciBpbmNsdWRlcyBvbmUgb3INCiAgYm90aCBhbGdvcml0aG0gbmFtZXMsICJyc2Etc2hh Mi0yNTYiIGFuZC9vciAicnNhLXNoYTItNTEyIiwgaW4gdGhlDQogIG5hbWUtbGlzdCBmaWVs ZCAic2VydmVyX2hvc3Rfa2V5X2FsZ29yaXRobXMiIGluIHRoZSBTU0hfTVNHX0tFWElOSVQN CiAgcGFja2V0IFtSRkM0MjUzXS4gSWYgb25lIG9mIHRoZSB0d28gaG9zdCBrZXkgYWxnb3Jp dGhtcyBpcyBuZWdvdGlhdGVkLA0KICB0aGUgc2VydmVyIHNlbmRzIGFuICJzc2gtcnNhIiBw dWJsaWMga2V5IGFzIHBhcnQgb2YgdGhlIG5lZ290aWF0ZWQga2V5DQogIGV4Y2hhbmdlIG1l dGhvZCAoZS5nLiBpbiBTU0hfTVNHX0tFWERIX1JFUExZKSwgYW5kIGVuY29kZXMgYSBzaWdu YXR1cmUNCiAgd2l0aCB0aGUgYXBwcm9wcmlhdGUgc2lnbmF0dXJlIGFsZ29yaXRobSBuYW1l IC0gZWl0aGVyICJyc2Etc2hhMi0yNTYiLA0KICBvciAicnNhLXNoYTItNTEyIi4NCiAgDQoy LjQuICBVc2UgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KDQogIFRvIHVzZSB0aGlzIGFs Z29yaXRobSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCB0aGUgU1NIIGNsaWVudCBzZW5k cw0KICBhbiBTU0hfTVNHX1VTRVJBVVRIX1JFUVVFU1QgbWVzc2FnZSBbUkZDNDI1Ml0gZW5j b2RpbmcgdGhlICJwdWJsaWNrZXkiDQogIG1ldGhvZCwgYW5kIGVuY29kaW5nIHRoZSBzdHJp bmcgZmllbGQgInB1YmxpYyBrZXkgYWxnb3JpdGhtIG5hbWUiIHdpdGgNCiAgdGhlIHZhbHVl ICJyc2Etc2hhMi0yNTYiIG9yICJyc2Etc2hhMi01MTIiLiBUaGUgInB1YmxpYyBrZXkgYmxv YiINCiAgZmllbGQgZW5jb2RlcyB0aGUgUlNBIHB1YmxpYyBrZXkgdXNpbmcgdGhlICJzc2gt cnNhIiBmb3JtYXQgaWRlbnRpZmllci4NCiAgVGhlIHNpZ25hdHVyZSBmaWVsZCwgaWYgcHJl c2VudCwgZW5jb2RlcyBhIHNpZ25hdHVyZSB1c2luZyBhbg0KICBzaWduYXR1cmUgZm9ybWF0 IGlkZW50aWZpZXIgdGhhdCBNVVNUIG1hdGNoIHRoZSBhbGdvcml0aG0gbmFtZSBpbiBTU0gg YXV0aGVudGljYXRpb24gcmVxdWVzdCAtIGVpdGhlcg0KICAicnNhLXNoYTItMjU2Iiwgb3Ig InJzYS1zaGEyLTUxMiIuDQoNCiAgRm9yIGV4YW1wbGUsIGFuIFNTSCAicHVibGlja2V5IiBz aWduZWQgYXV0aGVudGljYXRpb24gcmVxdWVzdCB1c2luZyBhbg0KICAicnNhLXNoYTItNTEy IiBhbGdvcml0aG0gd291bGQgYmUgcHJvcGVybHkgZW5jb2RlZCBhcyBmb2xsb3dzOg0KDQog ICAgYnl0ZSAgICAgIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVA0KICAgIHN0cmluZyAgICB1 c2VyIG5hbWUNCiAgICBzdHJpbmcgICAgc2VydmljZSBuYW1lDQogICAgc3RyaW5nICAgICJw dWJsaWNrZXkiDQogICAgYm9vbGVhbiAgIFRSVUUNCiAgICBzdHJpbmcgICAgInJzYS1zaGEy LTUxMiINCiAgICBzdHJpbmcgICAgcHVibGljIGtleSBibG9iOg0KICAgICAgICBzdHJpbmcg ICAgInNzaC1yc2EiDQogICAgICAgIG1waW50ICAgICBlDQogICAgICAgIG1waW50ICAgICBu DQogICAgc3RyaW5nICAgIHNpZ25hdHVyZToNCiAgICAgICAgc3RyaW5nICAgICJyc2Etc2hh Mi01MTIiDQogICAgICAgIHN0cmluZyAgICByc2Ffc2lnbmF0dXJlX2Jsb2INCiAgICANCg0K QmlkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIFJTQSBLZXlz IHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcNCg0KDQozLiAgRGlz Y292ZXJ5IG9mIHNpZ25hdHVyZSBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSBzZXJ2ZXJzDQoN CiAgSW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBoYXMgc2hvd24gdGhhdCB0aGVyZSBhcmUg c2VydmVycyB3aGljaCBhcHBseQ0KICBhdXRoZW50aWNhdGlvbiBwZW5hbHRpZXMgdG8gY2xp ZW50cyBhdHRlbXB0aW5nIHNpZ25hdHVyZSBhbGdvcml0aG1zDQogIHdoaWNoIHRoZSBTU0gg c2VydmVyIGRvZXMgbm90IHN1cHBvcnQuDQogIA0KICBTZXJ2ZXJzIHRoYXQgYWNjZXB0IHJz YS1zaGEyLSogc2lnbmF0dXJlcyBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQogIFNIT1VM RCBpbXBsZW1lbnQgdGhlIGV4dGVuc2lvbiBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZGVmaW5l ZCBpbg0KICBbU1NILUVYVC1JTkZPXSwgaW5jbHVkaW5nIGVzcGVjaWFsbHkgdGhlICJzZXJ2 ZXItc2lnLWFsZ3MiIGV4dGVuc2lvbi4NCiAgDQogIFdoZW4gYXV0aGVudGljYXRpbmcgd2l0 aCBhbiBSU0Ega2V5IGFnYWluc3QgYSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdA0KICBpbXBsZW1l bnQgdGhlICJzZXJ2ZXItc2lnLWFsZ3MiIGV4dGVuc2lvbiwgY2xpZW50cyBNQVkgZGVmYXVs dCB0byBhbg0KICBzc2gtcnNhIHNpZ25hdHVyZSB0byBhdm9pZCBhdXRoZW50aWNhdGlvbiBw ZW5hbHRpZXMuDQoNCjQuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgQ29uc2lzdGVudCB3 aXRoIFNlY3Rpb24gOCBvZiBbUkZDNDI1MV0gYW5kIFNlY3Rpb24gNC42IG9mIFtSRkM0MjUw XSwNCiAgdGhpcyBkb2N1bWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIHJlZ2lzdHJhdGlvbnM6 DQoNCiAgSW4gdGhlIFB1YmxpYyBLZXkgQWxnb3JpdGhtIE5hbWVzIHJlZ2lzdHJ5Og0KICAt IFRoZSBTU0ggcHVibGljIGtleSBhbGdvcml0aG0gInJzYS1zaGEyLTI1NiIuDQogIC0gVGhl IFNTSCBwdWJsaWMga2V5IGFsZ29yaXRobSAicnNhLXNoYTItNTEyIi4NCg0KICBUaGlzIGRv Y3VtZW50IGNyZWF0ZXMgbm8gbmV3IHJlZ2lzdHJpZXMuDQoNCjUuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucw0KDQogIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBbUkZDNDI1 M10gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4NCiAgIA0KICBUaGUgTmF0aW9uYWwgSW5zdGl0 dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neSAoTklTVCkgU3BlY2lhbA0KICBQdWJs aWNhdGlvbiA4MDAtMTMxQSBbODAwLTEzMUFdIGRpc2FsbG93cyB0aGUgdXNlIG9mIFJTQSBh bmQgRFNBIGtleXMNCiAgc2hvcnRlciB0aGFuIDIwNDggYml0cyBmb3IgVVMgZ292ZXJubWVu dCB1c2UgYWZ0ZXIgMjAxMy4gS2V5cyBvZiAyMDQ4DQogIGJpdHMgb3IgbGFyZ2VyIGFyZSBj b25zaWRlcmVkIGFjY2VwdGFibGUuDQogIA0KICBUaGUgc2FtZSBkb2N1bWVudCBkaXNhbGxv d3MgdGhlIFNIQS0xIGhhc2ggZnVuY3Rpb24sIGFzIHVzZWQgaW4gdGhlDQogICJzc2gtcnNh IiBhbmQgInNzaC1kc3MiIGFsZ29yaXRobXMsIGZvciBkaWdpdGFsIHNpZ25hdHVyZSBnZW5l cmF0aW9uDQogIGFmdGVyIDIwMTMuIFRoZSBTSEEtMiBmYW1pbHkgb2YgaGFzaCBmdW5jdGlv bnMgaXMgc2VlbiBhcyBhY2NlcHRhYmxlLg0KDQo2LiAgV2h5IG5vIERTQT8NCiAgDQogIEEg ZHJhZnQgdmVyc2lvbiBvZiB0aGlzIG1lbW8gYWxzbyBkZWZpbmVkIGFuIGFsZ29yaXRobSBu YW1lIGZvciB1c2Ugb2YNCiAgMjA0OC1iaXQgYW5kIDMwNzItYml0IERTQSBrZXlzIHdpdGgg YSAyNTYtYml0IHN1Ymdyb3VwIGFuZCBTSEEtMiAyNTYNCiAgaGFzaGluZy4gSXQgaXMgcG9z c2libGUgdG8gaW1wbGVtZW50IERTQSBzZWN1cmVseSBieSBnZW5lcmF0aW5nICJrIg0KICBk ZXRlcm1pbmlzdGljYWxseSBhcyBwZXIgW1JGQzY5NzldLiBIb3dldmVyLCBhIHBsdXJhbGl0 eSBvZiByZXZpZXdlcnMNCiAgd2VyZSBjb25jZXJuZWQgdGhhdCBpbXBsZW1lbnRlcnMgd291 bGQgY29udGludWUgdG8gdXNlIGxpYnJhcmllcyB0aGF0DQogDQoNCkJpZGVyICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBSU0EgS2V5cyB3aXRoIFNIQS0yIGlu IFNTSCAgICAgICAgICBGZWJydWFyeSAyMDE3DQogIA0KDQogIGdlbmVyYXRlICJrIiByYW5k b21seS4gVGhpcyBpcyB2dWxuZXJhYmxlIHRvIGJpYXNlZCAiayIgZ2VuZXJhdGlvbiwNCiAg YW5kIGV4dHJlbWVseSB2dWxuZXJhYmxlIHRvICJrIiByZXVzZS4NCg0KICBUaGlzIGRvY3Vt ZW50IHRoZXJlZm9yZSBhYnN0YWlucyBmcm9tIGRlZmluaW5nIG5ldyBhbGdvcml0aG0gbmFt ZXMNCiAgZm9yIERTQSwgYW5kIHJlY29tbWVuZHMgUlNBIHdoZXJlIHRoaXMgaXMgcHJlZmVy cmVkIG92ZXIgZWxsaXB0aWMNCiAgY3VydmUgY3J5cHRvZ3JhcGh5Lg0KDQoNCjcuICBSZWZl cmVuY2VzDQoNCjcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgW0ZJUFMtMTgwLTRd DQogICAgICAgICAgICAgIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRl Y2hub2xvZ3kgKE5JU1QpLA0KICAgICAgICAgICAgICBVbml0ZWQgU3RhdGVzIG9mIEFtZXJp Y2EsICJTZWN1cmUgSGFzaCBTdGFuZGFyZCAoU0hTKSIsDQogICAgICAgICAgICAgIEZJUFMg UHVibGljYXRpb24gMTgwLTQsIEF1Z3VzdCAyMDE1LA0KICAgICAgICAgICAgICA8aHR0cDov L2R4LmRvaS5vcmcvMTAuNjAyOC9OSVNULkZJUFMuMTgwLTQ+Lg0KDQogIFtSRkMyMTE5XSAg IEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0K ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBN YXJjaCAxOTk3Lg0KDQogIFtSRkMzNDQ3XSAgIEpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tp LCAiUHVibGljLUtleSBDcnlwdG9ncmFwaHkNCiAgICAgICAgICAgICAgU3RhbmRhcmRzIChQ S0NTKSAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9ucw0KICAgICAgICAgICAg ICBWZXJzaW9uIDIuMSIsIFJGQyAzNDQ3LCBGZWJydWFyeSAyMDAzLg0KDQogIFtSRkM0MjUw XSAgIExlaHRpbmVuLCBTLiBhbmQgQy4gTG9udmljaywgIlRoZSBTZWN1cmUgU2hlbGwgKFNT SCkNCiAgICAgICAgICAgICAgUHJvdG9jb2wgQXNzaWduZWQgTnVtYmVycyIsIFJGQyA0MjUw LCBKYW51YXJ5IDIwMDYuDQoNCiAgW1JGQzQyNTFdICAgWWxvbmVuLCBULiBhbmQgQy4gTG9u dmljaywgIlRoZSBTZWN1cmUgU2hlbGwgKFNTSCkNCiAgICAgICAgICAgICAgUHJvdG9jb2wg QXJjaGl0ZWN0dXJlIiwgUkZDIDQyNTEsIEphbnVhcnkgMjAwNi4NCg0KICBbUkZDNDI1Ml0g ICBZbG9uZW4sIFQuIGFuZCBDLiBMb252aWNrLCBFZC4sICJUaGUgU2VjdXJlIFNoZWxsIChT U0gpDQogICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIiwgUkZDIDQyNTIs IEphbnVhcnkgMjAwNi4NCg0KICBbUkZDNDI1M10gICBZbG9uZW4sIFQuIGFuZCBDLiBMb252 aWNrLCBFZC4sICJUaGUgU2VjdXJlIFNoZWxsIChTU0gpDQogICAgICAgICAgICAgIFRyYW5z cG9ydCBMYXllciBQcm90b2NvbCIsIFJGQyA0MjUzLCBKYW51YXJ5IDIwMDYuDQoNCjcuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICBbODAwLTEzMUFdICBOYXRpb25hbCBJbnN0 aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5IChOSVNUKSwNCiAgICAgICAgICAg ICAgIlRyYW5zaXRpb25zOiBSZWNvbW1lbmRhdGlvbiBmb3IgVHJhbnNpdGlvbmluZyB0aGUg VXNlIG9mDQogICAgICAgICAgICAgIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtcyBhbmQgS2V5 IExlbmd0aHMiLCBOSVNUIFNwZWNpYWwNCiAgICAgICAgICAgICAgUHVibGljYXRpb24gODAw LTEzMUEsIEphbnVhcnkgMjAxMSwgPGh0dHA6Ly9jc3JjLm5pc3QuZ292Lw0KICAgICAgICAg ICAgICBwdWJsaWNhdGlvbnMvbmlzdHB1YnMvODAwLTEzMUEvc3A4MDAtMTMxQS5wZGY+Lg0K DQogIFtSRkM0MjUwXSAgIExlaHRpbmVuLCBTLiBhbmQgQy4gTG9udmljaywgRWQuLCAiVGhl IFNlY3VyZSBTaGVsbCAoU1NIKQ0KICAgICAgICAgICAgICBQcm90b2NvbCBBc3NpZ25lZCBO dW1iZXJzIiwgUkZDIDQyNTAsIEphbnVhcnkgMjAwNi4NCg0KICBbUkZDNjk3OV0gICBQb3Ju aW4sIFQuLCAiRGV0ZXJtaW5pc3RpYyBVc2FnZSBvZiB0aGUgRGlnaXRhbA0KICAgICAgICAg ICAgICBTaWduYXR1cmUgQWxnb3JpdGhtIChEU0EpIGFuZCBFbGxpcHRpYyBDdXJ2ZSBEaWdp dGFsDQogICAgICAgICAgICAgIFNpZ25hdHVyZSBBbGdvcml0aG0gKEVDRFNBKSIsIFJGQyA2 OTc5LCBBdWd1c3QgMjAxMy4NCg0KICBbU1NILUVYVC1JTkZPXSANCiAgICAgICAgICAgICAg QmlkZXIsIEQuLCAiRXh0ZW5zaW9uIE5lZ290aWF0aW9uIGluIFNlY3VyZSBTaGVsbCAoU1NI KSIsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1leHQtaW5mby0wMi50 eHQsIEZlYnJ1YXJ5IDIwMTcsDQogICAgICAgICAgICAgIDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1leHQtaW5m by0wMj4uDQoNCg0KQmlkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgIFJTQSBLZXlzIHdpdGggU0hBLTIgaW4gU1NIICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcN Cg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAgRGVuaXMgQmlkZXINCiAgQml0dmlzZSBMaW1p dGVkDQogIFN1aXRlcyA0MS80MiwgVmljdG9yaWEgSG91c2UNCiAgMjYgTWFpbiBTdHJlZXQN CiAgR0kNCg0KICBQaG9uZTogKzUwNiA4MzE1IDY1MTkNCiAgRU1haWw6IGlldGYtc3NoM0Bk ZW5pc2JpZGVyLmNvbQ0KICBVUkk6ICAgaHR0cHM6Ly93d3cuYml0dmlzZS5jb20vDQoNCg0K QWNrbm93bGVkZ21lbnRzDQoNCiAgVGhhbmtzIHRvIEpvbiBCcmlnaHQsIE5pZWxzIE1vZWxs ZXIsIFN0ZXBoZW4gRmFycmVsbCwgTWFyayBELiBCYXVzaGtlLA0KICBKZWZmcmV5IEh1dHpl bG1hbiwgSGFubm8gQm9lY2ssIFBldGVyIEd1dG1hbm4sIERhbWllbiBNaWxsZXIsIGFuZCBN YXQNCiAgQmVyY2h0b2xkIGZvciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJpZGVyICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0K --------------020000000909070005050907 Content-Type: text/html; name="draft-ietf-curdle-rsa-sha2-03+rpetrov.wdiff.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-curdle-rsa-sha2-03+rpetrov.wdiff.html" ZGlmZiAtLWdpdCBhL2FwcHMvYXBwcy5oIGIvYXBwcy9hcHBzLmgKaW5kZXggZGU1MGRlNS4u M2MxZGE0OCAxMDA2NDQKLS0tIGEvYXBwcy9hcHBzLmgKKysrIGIvYXBwcy9hcHBzLmgKQEAg LTIxMyw5ICsyMTMsOSBAQCBpbnQgc2V0X2NlcnRfdGltZXMoWDUwOSAqeCwgY29uc3QgY2hh ciAqc3RhcnRkYXRlLCBjb25zdCBjaGFyICplbmRkYXRlLAogICAgICAgICBPUFRfU19OT1RM UzFfMywgT1BUX1NfQlVHUywgT1BUX1NfTk9fQ09NUCwgT1BUX1NfTk9USUNLRVQsIFwKICAg ICAgICAgT1BUX1NfU0VSVkVSUFJFRiwgT1BUX1NfTEVHQUNZUkVORUcsIE9QVF9TX0xFR0FD WUNPTk4sIFwKICAgICAgICAgT1BUX1NfT05SRVNVTVAsIE9QVF9TX05PTEVHQUNZQ09OTiwg T1BUX1NfU1RSSUNULCBPUFRfU19TSUdBTEdTLCBcCi0gICAgICAgIE9QVF9TX0NMSUVOVFNJ R0FMR1MsIE9QVF9TX0NVUlZFUywgT1BUX1NfTkFNRURDVVJWRSwgT1BUX1NfQ0lQSEVSLCBc Ci0gICAgICAgIE9QVF9TX0RIUEFSQU0sIE9QVF9TX1JFQ09SRF9QQURESU5HLCBPUFRfU19E RUJVR0JST0tFLCBPUFRfU19DT01QLCBcCi0gICAgICAgIE9QVF9TX19MQVNUCisgICAgICAg IE9QVF9TX0NMSUVOVFNJR0FMR1MsIE9QVF9TX0dST1VQUywgT1BUX1NfQ1VSVkVTLCBPUFRf U19OQU1FRENVUlZFLCBcCisgICAgICAgIE9QVF9TX0NJUEhFUiwgT1BUX1NfREhQQVJBTSwg T1BUX1NfUkVDT1JEX1BBRERJTkcsIE9QVF9TX0RFQlVHQlJPS0UsIFwKKyAgICAgICAgT1BU X1NfQ09NUCwgT1BUX1NfX0xBU1QKIAogIyBkZWZpbmUgT1BUX1NfT1BUSU9OUyBcCiAgICAg ICAgIHsibm9fc3NsMyIsIE9QVF9TX05PU1NMMywgJy0nLCJKdXN0IGRpc2FibGUgU1NMdjMi IH0sIFwKQEAgLTI0NCw4ICsyNDQsMTAgQEAgaW50IHNldF9jZXJ0X3RpbWVzKFg1MDkgKngs IGNvbnN0IGNoYXIgKnN0YXJ0ZGF0ZSwgY29uc3QgY2hhciAqZW5kZGF0ZSwKICAgICAgICAg eyJjbGllbnRfc2lnYWxncyIsIE9QVF9TX0NMSUVOVFNJR0FMR1MsICdzJywgXAogICAgICAg ICAgICAgIlNpZ25hdHVyZSBhbGdvcml0aG1zIHRvIHN1cHBvcnQgZm9yIGNsaWVudCBjZXJ0 aWZpY2F0ZSIgXAogICAgICAgICAgICAgIiBhdXRoZW50aWNhdGlvbiAoY29sb24tc2VwYXJh dGVkIGxpc3QpIiB9LCBcCisgICAgICAgIHsiZ3JvdXBzIiwgT1BUX1NfR1JPVVBTLCAncycs IFwKKyAgICAgICAgICAgICJHcm91cHMgdG8gYWR2ZXJ0aXNlIChjb2xvbi1zZXBhcmF0ZWQg bGlzdCkiIH0sIFwKICAgICAgICAgeyJjdXJ2ZXMiLCBPUFRfU19DVVJWRVMsICdzJywgXAot ICAgICAgICAgICAgIkVsbGlwdGljIGN1cnZlcyB0byBhZHZlcnRpc2UgKGNvbG9uLXNlcGFy YXRlZCBsaXN0KSIgfSwgXAorICAgICAgICAgICAgIkdyb3VwcyB0byBhZHZlcnRpc2UgKGNv bG9uLXNlcGFyYXRlZCBsaXN0KSIgfSwgXAogICAgICAgICB7Im5hbWVkX2N1cnZlIiwgT1BU X1NfTkFNRURDVVJWRSwgJ3MnLCBcCiAgICAgICAgICAgICAiRWxsaXB0aWMgY3VydmUgdXNl ZCBmb3IgRUNESEUgKHNlcnZlci1zaWRlIG9ubHkpIiB9LCBcCiAgICAgICAgIHsiY2lwaGVy IiwgT1BUX1NfQ0lQSEVSLCAncycsICJTcGVjaWZ5IGNpcGhlciBsaXN0IHRvIGJlIHVzZWQi fSwgXApAQCAtMjc2LDYgKzI3OCw3IEBAIGludCBzZXRfY2VydF90aW1lcyhYNTA5ICp4LCBj b25zdCBjaGFyICpzdGFydGRhdGUsIGNvbnN0IGNoYXIgKmVuZGRhdGUsCiAgICAgICAgIGNh c2UgT1BUX1NfU1RSSUNUOiBcCiAgICAgICAgIGNhc2UgT1BUX1NfU0lHQUxHUzogXAogICAg ICAgICBjYXNlIE9QVF9TX0NMSUVOVFNJR0FMR1M6IFwKKyAgICAgICAgY2FzZSBPUFRfU19H Uk9VUFM6IFwKICAgICAgICAgY2FzZSBPUFRfU19DVVJWRVM6IFwKICAgICAgICAgY2FzZSBP UFRfU19OQU1FRENVUlZFOiBcCiAgICAgICAgIGNhc2UgT1BUX1NfQ0lQSEVSOiBcCmRpZmYg LS1naXQgYS9hcHBzL29wZW5zc2wtdm1zLmNuZiBiL2FwcHMvb3BlbnNzbC12bXMuY25mCmlu ZGV4IDAwOTJhNjUuLmEzY2EzOTMgMTAwNjQ0Ci0tLSBhL2FwcHMvb3BlbnNzbC12bXMuY25m CisrKyBiL2FwcHMvb3BlbnNzbC12bXMuY25mCkBAIC0zNDQsMyArMzQ0LDUgQEAgdHNhX25h bWUJCT0geWVzCSMgTXVzdCB0aGUgVFNBIG5hbWUgYmUgaW5jbHVkZWQgaW4gdGhlIHJlcGx5 PwogCQkJCSMgKG9wdGlvbmFsLCBkZWZhdWx0OiBubykKIGVzc19jZXJ0X2lkX2NoYWluCT0g bm8JIyBNdXN0IHRoZSBFU1MgY2VydCBpZCBjaGFpbiBiZSBpbmNsdWRlZD8KIAkJCQkjIChv cHRpb25hbCwgZGVmYXVsdDogbm8pCitlc3NfY2VydF9pZF9hbGcJCT0gc2hhMQkjIGFsZ29y aXRobSB0byBjb21wdXRlIGNlcnRpZmljYXRlCisJCQkJIyBpZGVudGlmaWVyIChvcHRpb25h bCwgZGVmYXVsdDogc2hhMSkKZGlmZiAtLWdpdCBhL2FwcHMvb3BlbnNzbC5jbmYgYi9hcHBz L29wZW5zc2wuY25mCmluZGV4IGIzZTc0NDQuLjMyZWU5ZTkgMTAwNjQ0Ci0tLSBhL2FwcHMv b3BlbnNzbC5jbmYKKysrIGIvYXBwcy9vcGVuc3NsLmNuZgpAQCAtMzQ0LDMgKzM0NCw1IEBA IHRzYV9uYW1lCQk9IHllcwkjIE11c3QgdGhlIFRTQSBuYW1lIGJlIGluY2x1ZGVkIGluIHRo ZSByZXBseT8KIAkJCQkjIChvcHRpb25hbCwgZGVmYXVsdDogbm8pCiBlc3NfY2VydF9pZF9j aGFpbgk9IG5vCSMgTXVzdCB0aGUgRVNTIGNlcnQgaWQgY2hhaW4gYmUgaW5jbHVkZWQ/CiAJ CQkJIyAob3B0aW9uYWwsIGRlZmF1bHQ6IG5vKQorZXNzX2NlcnRfaWRfYWxnCQk9IHNoYTEJ IyBhbGdvcml0aG0gdG8gY29tcHV0ZSBjZXJ0aWZpY2F0ZQorCQkJCSMgaWRlbnRpZmllciAo b3B0aW9uYWwsIGRlZmF1bHQ6IHNoYTEpCmRpZmYgLS1naXQgYS9hcHBzL3RzLmMgYi9hcHBz L3RzLmMKaW5kZXggMGRiNmI1MC4uZTgxNmMzMiAxMDA2NDQKLS0tIGEvYXBwcy90cy5jCisr KyBiL2FwcHMvdHMuYwpAQCAtNzA5LDYgKzcwOSw4IEBAIHN0YXRpYyBUU19SRVNQICpjcmVh dGVfcmVzcG9uc2UoQ09ORiAqY29uZiwgY29uc3QgY2hhciAqc2VjdGlvbiwgY29uc3QgY2hh ciAqZW5nCiAgICAgICAgICAgICBnb3RvIGVuZDsKICAgICB9CiAKKyAgICBpZiAoIVRTX0NP TkZfc2V0X2Vzc19jZXJ0X2lkX2RpZ2VzdChjb25mLCBzZWN0aW9uLCByZXNwX2N0eCkpCisg ICAgICAgIGdvdG8gZW5kOwogICAgIGlmICghVFNfQ09ORl9zZXRfZGVmX3BvbGljeShjb25m LCBzZWN0aW9uLCBwb2xpY3ksIHJlc3BfY3R4KSkKICAgICAgICAgZ290byBlbmQ7CiAgICAg aWYgKCFUU19DT05GX3NldF9wb2xpY2llcyhjb25mLCBzZWN0aW9uLCByZXNwX2N0eCkpCmRp ZmYgLS1naXQgYS9jcnlwdG8vb2JqZWN0cy9vYmpfZGF0LmggYi9jcnlwdG8vb2JqZWN0cy9v YmpfZGF0LmgKaW5kZXggOTM4NDNlMS4uZDE5NDJjMCAxMDA2NDQKLS0tIGEvY3J5cHRvL29i amVjdHMvb2JqX2RhdC5oCisrKyBiL2NyeXB0by9vYmplY3RzL29ial9kYXQuaApAQCAtMTAs NyArMTAsNyBAQAogICovCiAKIC8qIFNlcmlhbGl6ZWQgT0lEJ3MgKi8KLXN0YXRpYyBjb25z dCB1bnNpZ25lZCBjaGFyIHNvWzY5MDBdID0geworc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNo YXIgc29bNjkxMV0gPSB7CiAgICAgMHgyQSwweDg2LDB4NDgsMHg4NiwweEY3LDB4MEQsICAg ICAgICAgICAgICAgICAvKiBbICAgIDBdIE9CSl9yc2Fkc2kgKi8KICAgICAweDJBLDB4ODYs MHg0OCwweDg2LDB4RjcsMHgwRCwweDAxLCAgICAgICAgICAgIC8qIFsgICAgNl0gT0JKX3Br Y3MgKi8KICAgICAweDJBLDB4ODYsMHg0OCwweDg2LDB4RjcsMHgwRCwweDAyLDB4MDIsICAg ICAgIC8qIFsgICAxM10gT0JKX21kMiAqLwpAQCAtOTc2LDkgKzk3NiwxMCBAQCBzdGF0aWMg Y29uc3QgdW5zaWduZWQgY2hhciBzb1s2OTAwXSA9IHsKICAgICAweDJBLDB4ODMsMHgxQSww eDhDLDB4OUEsMHg2RSwweDAxLDB4MDEsMHgwRCwgIC8qIFsgNjg3Ml0gT0JKX2FyaWFfMjU2 X2NmYjEyOCAqLwogICAgIDB4MkEsMHg4MywweDFBLDB4OEMsMHg5QSwweDZFLDB4MDEsMHgw MSwweDBFLCAgLyogWyA2ODgxXSBPQkpfYXJpYV8yNTZfb2ZiMTI4ICovCiAgICAgMHgyQSww eDgzLDB4MUEsMHg4QywweDlBLDB4NkUsMHgwMSwweDAxLDB4MEYsICAvKiBbIDY4OTBdIE9C Sl9hcmlhXzI1Nl9jdHIgKi8KKyAgICAweDJBLDB4ODYsMHg0OCwweDg2LDB4RjcsMHgwRCww eDAxLDB4MDksMHgxMCwweDAyLDB4MUUsICAvKiBbIDY4OTldIE9CSl9pZF9zbWltZV9hYV9z aWduaW5nQ2VydGlmaWNhdGVWMiAqLwogfTsKIAotI2RlZmluZSBOVU1fTklEIDEwODYKKyNk ZWZpbmUgTlVNX05JRCAxMDg3CiBzdGF0aWMgY29uc3QgQVNOMV9PQkpFQ1QgbmlkX29ianNb TlVNX05JRF0gPSB7CiAgICAgeyJVTkRFRiIsICJ1bmRlZmluZWQiLCBOSURfdW5kZWZ9LAog ICAgIHsicnNhZHNpIiwgIlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuIiwgTklEX3JzYWRzaSwg NiwgJnNvWzBdfSwKQEAgLTIwNjYsOSArMjA2NywxMCBAQCBzdGF0aWMgY29uc3QgQVNOMV9P QkpFQ1QgbmlkX29ianNbTlVNX05JRF0gPSB7CiAgICAgeyJBUklBLTEyOC1DRkI4IiwgImFy aWEtMTI4LWNmYjgiLCBOSURfYXJpYV8xMjhfY2ZiOH0sCiAgICAgeyJBUklBLTE5Mi1DRkI4 IiwgImFyaWEtMTkyLWNmYjgiLCBOSURfYXJpYV8xOTJfY2ZiOH0sCiAgICAgeyJBUklBLTI1 Ni1DRkI4IiwgImFyaWEtMjU2LWNmYjgiLCBOSURfYXJpYV8yNTZfY2ZiOH0sCisgICAgeyJp ZC1zbWltZS1hYS1zaWduaW5nQ2VydGlmaWNhdGVWMiIsICJpZC1zbWltZS1hYS1zaWduaW5n Q2VydGlmaWNhdGVWMiIsIE5JRF9pZF9zbWltZV9hYV9zaWduaW5nQ2VydGlmaWNhdGVWMiwg MTEsICZzb1s2ODk5XX0sCiB9OwogCi0jZGVmaW5lIE5VTV9TTiAxMDc3CisjZGVmaW5lIE5V TV9TTiAxMDc4CiBzdGF0aWMgY29uc3QgdW5zaWduZWQgaW50IHNuX29ianNbTlVNX1NOXSA9 IHsKICAgICAgMzY0LCAgICAvKiAiQURfRFZDUyIgKi8KICAgICAgNDE5LCAgICAvKiAiQUVT LTEyOC1DQkMiICovCkBAIC0yNzEyLDYgKzI3MTQsNyBAQCBzdGF0aWMgY29uc3QgdW5zaWdu ZWQgaW50IHNuX29ianNbTlVNX1NOXSA9IHsKICAgICAgMjEzLCAgICAvKiAiaWQtc21pbWUt YWEtc2VjdXJpdHlMYWJlbCIgKi8KICAgICAgMjM5LCAgICAvKiAiaWQtc21pbWUtYWEtc2ln bmF0dXJlVHlwZSIgKi8KICAgICAgMjIzLCAgICAvKiAiaWQtc21pbWUtYWEtc2lnbmluZ0Nl cnRpZmljYXRlIiAqLworICAgIDEwODYsICAgIC8qICJpZC1zbWltZS1hYS1zaWduaW5nQ2Vy dGlmaWNhdGVWMiIgKi8KICAgICAgMjI0LCAgICAvKiAiaWQtc21pbWUtYWEtc21pbWVFbmNy eXB0Q2VydHMiICovCiAgICAgIDIyNSwgICAgLyogImlkLXNtaW1lLWFhLXRpbWVTdGFtcFRv a2VuIiAqLwogICAgICAxOTIsICAgIC8qICJpZC1zbWltZS1hbGciICovCkBAIC0zMTQ5LDcg KzMxNTIsNyBAQCBzdGF0aWMgY29uc3QgdW5zaWduZWQgaW50IHNuX29ianNbTlVNX1NOXSA9 IHsKICAgICAgMTYwLCAgICAvKiAieDUwOUNybCIgKi8KIH07CiAKLSNkZWZpbmUgTlVNX0xO IDEwNzcKKyNkZWZpbmUgTlVNX0xOIDEwNzgKIHN0YXRpYyBjb25zdCB1bnNpZ25lZCBpbnQg bG5fb2Jqc1tOVU1fTE5dID0gewogICAgICAzNjMsICAgIC8qICJBRCBUaW1lIFN0YW1waW5n IiAqLwogICAgICA0MDUsICAgIC8qICJBTlNJIFg5LjYyIiAqLwpAQCAtMzc4Niw2ICszNzg5 LDcgQEAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGludCBsbl9vYmpzW05VTV9MTl0gPSB7CiAg ICAgIDIxMywgICAgLyogImlkLXNtaW1lLWFhLXNlY3VyaXR5TGFiZWwiICovCiAgICAgIDIz OSwgICAgLyogImlkLXNtaW1lLWFhLXNpZ25hdHVyZVR5cGUiICovCiAgICAgIDIyMywgICAg LyogImlkLXNtaW1lLWFhLXNpZ25pbmdDZXJ0aWZpY2F0ZSIgKi8KKyAgICAxMDg2LCAgICAv KiAiaWQtc21pbWUtYWEtc2lnbmluZ0NlcnRpZmljYXRlVjIiICovCiAgICAgIDIyNCwgICAg LyogImlkLXNtaW1lLWFhLXNtaW1lRW5jcnlwdENlcnRzIiAqLwogICAgICAyMjUsICAgIC8q ICJpZC1zbWltZS1hYS10aW1lU3RhbXBUb2tlbiIgKi8KICAgICAgMTkyLCAgICAvKiAiaWQt c21pbWUtYWxnIiAqLwpAQCAtNDIzMCw3ICs0MjM0LDcgQEAgc3RhdGljIGNvbnN0IHVuc2ln bmVkIGludCBsbl9vYmpzW05VTV9MTl0gPSB7CiAgICAgIDEyNSwgICAgLyogInpsaWIgY29t cHJlc3Npb24iICovCiB9OwogCi0jZGVmaW5lIE5VTV9PQkogOTcxCisjZGVmaW5lIE5VTV9P QkogOTcyCiBzdGF0aWMgY29uc3QgdW5zaWduZWQgaW50IG9ial9vYmpzW05VTV9PQkpdID0g ewogICAgICAgIDAsICAgIC8qIE9CSl91bmRlZiAgICAgICAgICAgICAgICAgICAgICAgIDAg Ki8KICAgICAgMTgxLCAgICAvKiBPQkpfaXNvICAgICAgICAgICAgICAgICAgICAgICAgICAx ICovCkBAIC01MTczLDYgKzUxNzcsNyBAQCBzdGF0aWMgY29uc3QgdW5zaWduZWQgaW50IG9i al9vYmpzW05VTV9PQkpdID0gewogICAgICAyMzgsICAgIC8qIE9CSl9pZF9zbWltZV9hYV9l dHNfYXJjaGl2ZVRpbWVTdGFtcCAxIDIgODQwIDExMzU0OSAxIDkgMTYgMiAyNyAqLwogICAg ICAyMzksICAgIC8qIE9CSl9pZF9zbWltZV9hYV9zaWduYXR1cmVUeXBlICAgIDEgMiA4NDAg MTEzNTQ5IDEgOSAxNiAyIDI4ICovCiAgICAgIDI0MCwgICAgLyogT0JKX2lkX3NtaW1lX2Fh X2R2Y3NfZHZjICAgICAgICAgMSAyIDg0MCAxMTM1NDkgMSA5IDE2IDIgMjkgKi8KKyAgICAx MDg2LCAgICAvKiBPQkpfaWRfc21pbWVfYWFfc2lnbmluZ0NlcnRpZmljYXRlVjIgMSAyIDg0 MCAxMTM1NDkgMSA5IDE2IDIgMzAgKi8KICAgICAgMjQxLCAgICAvKiBPQkpfaWRfc21pbWVf YWxnX0VTREh3aXRoM0RFUyAgICAxIDIgODQwIDExMzU0OSAxIDkgMTYgMyAxICovCiAgICAg IDI0MiwgICAgLyogT0JKX2lkX3NtaW1lX2FsZ19FU0RId2l0aFJDMiAgICAgMSAyIDg0MCAx MTM1NDkgMSA5IDE2IDMgMiAqLwogICAgICAyNDMsICAgIC8qIE9CSl9pZF9zbWltZV9hbGdf M0RFU3dyYXAgICAgICAgIDEgMiA4NDAgMTEzNTQ5IDEgOSAxNiAzIDMgKi8KZGlmZiAtLWdp dCBhL2NyeXB0by9vYmplY3RzL29ial9tYWMubnVtIGIvY3J5cHRvL29iamVjdHMvb2JqX21h Yy5udW0KaW5kZXggMjcwZTdlNS4uY2E4ZGNkYiAxMDA2NDQKLS0tIGEvY3J5cHRvL29iamVj dHMvb2JqX21hYy5udW0KKysrIGIvY3J5cHRvL29iamVjdHMvb2JqX21hYy5udW0KQEAgLTEw ODMsMyArMTA4Myw0IEBAIGFyaWFfMjU2X2NmYjEJCTEwODIKIGFyaWFfMTI4X2NmYjgJCTEw ODMKIGFyaWFfMTkyX2NmYjgJCTEwODQKIGFyaWFfMjU2X2NmYjgJCTEwODUKK2lkX3NtaW1l X2FhX3NpZ25pbmdDZXJ0aWZpY2F0ZVYyCQkxMDg2CmRpZmYgLS1naXQgYS9jcnlwdG8vb2Jq ZWN0cy9vYmplY3RzLnR4dCBiL2NyeXB0by9vYmplY3RzL29iamVjdHMudHh0CmluZGV4IDQ0 MmIzOWMuLmYxOWM1Y2UgMTAwNjQ0Ci0tLSBhL2NyeXB0by9vYmplY3RzL29iamVjdHMudHh0 CisrKyBiL2NyeXB0by9vYmplY3RzL29iamVjdHMudHh0CkBAIC0yOTQsNiArMjk0LDcgQEAg aWQtc21pbWUtYWEgMjYJCTogaWQtc21pbWUtYWEtZXRzLWNlcnRDUkxUaW1lc3RhbXAKIGlk LXNtaW1lLWFhIDI3CQk6IGlkLXNtaW1lLWFhLWV0cy1hcmNoaXZlVGltZVN0YW1wCiBpZC1z bWltZS1hYSAyOAkJOiBpZC1zbWltZS1hYS1zaWduYXR1cmVUeXBlCiBpZC1zbWltZS1hYSAy OQkJOiBpZC1zbWltZS1hYS1kdmNzLWR2YworaWQtc21pbWUtYWEgMzAJCTogaWQtc21pbWUt YWEtc2lnbmluZ0NlcnRpZmljYXRlVjIKIAogIyBTL01JTUUgQWxnb3JpdGhtIElkZW50aWZp ZXJzCiAjIG9ic29sZXRlCmRpZmYgLS1naXQgYS9jcnlwdG8vdHMvdHNfYXNuMS5jIGIvY3J5 cHRvL3RzL3RzX2FzbjEuYwppbmRleCBlNjA2NzVhLi44NzA3MjA3IDEwMDY0NAotLS0gYS9j cnlwdG8vdHMvdHNfYXNuMS5jCisrKyBiL2NyeXB0by90cy90c19hc24xLmMKQEAgLTIyNSw2 ICsyMjUsMjMgQEAgQVNOMV9TRVFVRU5DRShFU1NfU0lHTklOR19DRVJUKSA9IHsKIElNUExF TUVOVF9BU04xX0ZVTkNUSU9OU19jb25zdChFU1NfU0lHTklOR19DRVJUKQogSU1QTEVNRU5U X0FTTjFfRFVQX0ZVTkNUSU9OKEVTU19TSUdOSU5HX0NFUlQpCiAKK0FTTjFfU0VRVUVOQ0Uo RVNTX0NFUlRfSURfVjIpID0geworICAgICAgICBBU04xX09QVChFU1NfQ0VSVF9JRF9WMiwg aGFzaF9hbGcsIFg1MDlfQUxHT1IpLAorICAgICAgICBBU04xX1NJTVBMRShFU1NfQ0VSVF9J RF9WMiwgaGFzaCwgQVNOMV9PQ1RFVF9TVFJJTkcpLAorICAgICAgICBBU04xX09QVChFU1Nf Q0VSVF9JRF9WMiwgaXNzdWVyX3NlcmlhbCwgRVNTX0lTU1VFUl9TRVJJQUwpCit9IHN0YXRp Y19BU04xX1NFUVVFTkNFX0VORChFU1NfQ0VSVF9JRF9WMikKKworSU1QTEVNRU5UX0FTTjFf RlVOQ1RJT05TX2NvbnN0KEVTU19DRVJUX0lEX1YyKQorSU1QTEVNRU5UX0FTTjFfRFVQX0ZV TkNUSU9OKEVTU19DRVJUX0lEX1YyKQorCitBU04xX1NFUVVFTkNFKEVTU19TSUdOSU5HX0NF UlRfVjIpID0geworICAgICAgICBBU04xX1NFUVVFTkNFX09GKEVTU19TSUdOSU5HX0NFUlRf VjIsIGNlcnRfaWRzLCBFU1NfQ0VSVF9JRF9WMiksCisgICAgICAgIEFTTjFfU0VRVUVOQ0Vf T0ZfT1BUKEVTU19TSUdOSU5HX0NFUlRfVjIsIHBvbGljeV9pbmZvLCBQT0xJQ1lJTkZPKQor fSBzdGF0aWNfQVNOMV9TRVFVRU5DRV9FTkQoRVNTX1NJR05JTkdfQ0VSVF9WMikKKworSU1Q TEVNRU5UX0FTTjFfRlVOQ1RJT05TX2NvbnN0KEVTU19TSUdOSU5HX0NFUlRfVjIpCitJTVBM RU1FTlRfQVNOMV9EVVBfRlVOQ1RJT04oRVNTX1NJR05JTkdfQ0VSVF9WMikKKwogLyogR2V0 dGluZyBlbmNhcHN1bGF0ZWQgVFNfVFNUX0lORk8gb2JqZWN0IGZyb20gUEtDUzcuICovCiBU U19UU1RfSU5GTyAqUEtDUzdfdG9fVFNfVFNUX0lORk8oUEtDUzcgKnRva2VuKQogewpkaWZm IC0tZ2l0IGEvY3J5cHRvL3RzL3RzX2NvbmYuYyBiL2NyeXB0by90cy90c19jb25mLmMKaW5k ZXggZjVmMzkzNC4uNjI1MDg5YSAxMDA2NDQKLS0tIGEvY3J5cHRvL3RzL3RzX2NvbmYuYwor KysgYi9jcnlwdG8vdHMvdHNfY29uZi5jCkBAIC0zNyw2ICszNyw3IEBACiAjZGVmaW5lIEVO Vl9DTE9DS19QUkVDSVNJT05fRElHSVRTICAgICAgImNsb2NrX3ByZWNpc2lvbl9kaWdpdHMi CiAjZGVmaW5lIEVOVl9WQUxVRV9ZRVMgICAgICAgICAgICAgICAgICAgInllcyIKICNkZWZp bmUgRU5WX1ZBTFVFX05PICAgICAgICAgICAgICAgICAgICAibm8iCisjZGVmaW5lIEVOVl9F U1NfQ0VSVF9JRF9BTEcgICAgICAgICAgICAgImVzc19jZXJ0X2lkX2FsZyIKIAogLyogRnVu Y3Rpb24gZGVmaW5pdGlvbnMgZm9yIGNlcnRpZmljYXRlIGFuZCBrZXkgbG9hZGluZy4gKi8K IApAQCAtNDY2LDMgKzQ2NywyNyBAQCBpbnQgVFNfQ09ORl9zZXRfZXNzX2NlcnRfaWRfY2hh aW4oQ09ORiAqY29uZiwgY29uc3QgY2hhciAqc2VjdGlvbiwKICAgICByZXR1cm4gdHNfQ09O Rl9hZGRfZmxhZyhjb25mLCBzZWN0aW9uLCBFTlZfRVNTX0NFUlRfSURfQ0hBSU4sCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVFNfRVNTX0NFUlRfSURfQ0hBSU4sIGN0eCk7CiB9 CisKK2ludCBUU19DT05GX3NldF9lc3NfY2VydF9pZF9kaWdlc3QoQ09ORiAqY29uZiwgY29u c3QgY2hhciAqc2VjdGlvbiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VFNfUkVTUF9DVFggKmN0eCkKK3sKKyAgICBpbnQgcmV0ID0gMDsKKyAgICBjb25zdCBFVlBf TUQgKmNlcnRfbWQgPSBOVUxMOworICAgIGNvbnN0IGNoYXIgKm1kID0gTkNPTkZfZ2V0X3N0 cmluZyhjb25mLCBzZWN0aW9uLCBFTlZfRVNTX0NFUlRfSURfQUxHKTsKKworICAgIGlmICht ZCA9PSBOVUxMKQorICAgICAgICBtZCA9ICJzaGExIjsKKworICAgIGNlcnRfbWQgPSBFVlBf Z2V0X2RpZ2VzdGJ5bmFtZShtZCk7CisgICAgaWYgKGNlcnRfbWQgPT0gTlVMTCkgeworICAg ICAgICB0c19DT05GX2ludmFsaWQoc2VjdGlvbiwgRU5WX0VTU19DRVJUX0lEX0FMRyk7Cisg ICAgICAgIGdvdG8gZXJyOworICAgIH0KKworICAgIGlmICghVFNfUkVTUF9DVFhfc2V0X2Vz c19jZXJ0X2lkX2RpZ2VzdChjdHgsIGNlcnRfbWQpKQorICAgICAgICBnb3RvIGVycjsKKwor ICAgIHJldCA9IDE7CitlcnI6CisgICAgcmV0dXJuIHJldDsKK30KZGlmZiAtLWdpdCBhL2Ny eXB0by90cy90c19lcnIuYyBiL2NyeXB0by90cy90c19lcnIuYwppbmRleCBhNmQ3M2ExLi41 YWVkMDQ2IDEwMDY0NAotLS0gYS9jcnlwdG8vdHMvdHNfZXJyLmMKKysrIGIvY3J5cHRvL3Rz L3RzX2Vyci5jCkBAIC0xLDYgKzEsNiBAQAogLyoKICAqIEdlbmVyYXRlZCBieSB1dGlsL21r ZXJyLnBsIERPIE5PVCBFRElUCi0gKiBDb3B5cmlnaHQgMTk5NS0yMDE2IFRoZSBPcGVuU1NM IFByb2plY3QgQXV0aG9ycy4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4KKyAqIENvcHlyaWdodCAx OTk1LTIwMTcgVGhlIE9wZW5TU0wgUHJvamVjdCBBdXRob3JzLiBBbGwgUmlnaHRzIFJlc2Vy dmVkLgogICoKICAqIExpY2Vuc2VkIHVuZGVyIHRoZSBPcGVuU1NMIGxpY2Vuc2UgKHRoZSAi TGljZW5zZSIpLiAgWW91IG1heSBub3QgdXNlCiAgKiB0aGlzIGZpbGUgZXhjZXB0IGluIGNv bXBsaWFuY2Ugd2l0aCB0aGUgTGljZW5zZS4gIFlvdSBjYW4gb2J0YWluIGEgY29weQpAQCAt MjIsOCArMjIsMTIgQEAgc3RhdGljIEVSUl9TVFJJTkdfREFUQSBUU19zdHJfZnVuY3RzW10g PSB7CiAgICAge0VSUl9GVU5DKFRTX0ZfREVGX1NFUklBTF9DQiksICJkZWZfc2VyaWFsX2Ni In0sCiAgICAge0VSUl9GVU5DKFRTX0ZfREVGX1RJTUVfQ0IpLCAiZGVmX3RpbWVfY2IifSwK ICAgICB7RVJSX0ZVTkMoVFNfRl9FU1NfQUREX1NJR05JTkdfQ0VSVCksICJFU1NfYWRkX3Np Z25pbmdfY2VydCJ9LAorICAgIHtFUlJfRlVOQyhUU19GX0VTU19BRERfU0lHTklOR19DRVJU X1YyKSwgImVzc19hZGRfc2lnbmluZ19jZXJ0X3YyIn0sCiAgICAge0VSUl9GVU5DKFRTX0Zf RVNTX0NFUlRfSURfTkVXX0lOSVQpLCAiZXNzX0NFUlRfSURfbmV3X2luaXQifSwKKyAgICB7 RVJSX0ZVTkMoVFNfRl9FU1NfQ0VSVF9JRF9WMl9ORVdfSU5JVCksICJlc3NfY2VydF9pZF9u ZXdfaW5pdCJ9LAogICAgIHtFUlJfRlVOQyhUU19GX0VTU19TSUdOSU5HX0NFUlRfTkVXX0lO SVQpLCAiZXNzX1NJR05JTkdfQ0VSVF9uZXdfaW5pdCJ9LAorICAgIHtFUlJfRlVOQyhUU19G X0VTU19TSUdOSU5HX0NFUlRfVjJfTkVXX0lOSVQpLAorICAgICAiZXNzX3NpZ25pbmdfY2Vy dF9WMl9uZXdfaW5pdCJ9LAogICAgIHtFUlJfRlVOQyhUU19GX0lOVF9UU19SRVNQX1ZFUklG WV9UT0tFTiksICJpbnRfdHNfUkVTUF92ZXJpZnlfdG9rZW4ifSwKICAgICB7RVJSX0ZVTkMo VFNfRl9QS0NTN19UT19UU19UU1RfSU5GTyksICJQS0NTN190b19UU19UU1RfSU5GTyJ9LAog ICAgIHtFUlJfRlVOQyhUU19GX1RTX0FDQ1VSQUNZX1NFVF9NSUNST1MpLCAiVFNfQUNDVVJB Q1lfc2V0X21pY3JvcyJ9LApAQCAtOTIsNiArOTYsOCBAQCBzdGF0aWMgRVJSX1NUUklOR19E QVRBIFRTX3N0cl9yZWFzb25zW10gPSB7CiAgICAge0VSUl9SRUFTT04oVFNfUl9ERVRBQ0hF RF9DT05URU5UKSwgImRldGFjaGVkIGNvbnRlbnQifSwKICAgICB7RVJSX1JFQVNPTihUU19S X0VTU19BRERfU0lHTklOR19DRVJUX0VSUk9SKSwKICAgICAgImVzcyBhZGQgc2lnbmluZyBj ZXJ0IGVycm9yIn0sCisgICAge0VSUl9SRUFTT04oVFNfUl9FU1NfQUREX1NJR05JTkdfQ0VS VF9WMl9FUlJPUiksCisgICAgICJlc3MgYWRkIHNpZ25pbmcgY2VydCB2MiBlcnJvciJ9LAog ICAgIHtFUlJfUkVBU09OKFRTX1JfRVNTX1NJR05JTkdfQ0VSVElGSUNBVEVfRVJST1IpLAog ICAgICAiZXNzIHNpZ25pbmcgY2VydGlmaWNhdGUgZXJyb3IifSwKICAgICB7RVJSX1JFQVNP TihUU19SX0lOVkFMSURfTlVMTF9QT0lOVEVSKSwgImludmFsaWQgbnVsbCBwb2ludGVyIn0s CmRpZmYgLS1naXQgYS9jcnlwdG8vdHMvdHNfbGNsLmggYi9jcnlwdG8vdHMvdHNfbGNsLmgK aW5kZXggZDBjM2NmOC4uNzcxNzg0ZiAxMDA2NDQKLS0tIGEvY3J5cHRvL3RzL3RzX2xjbC5o CisrKyBiL2NyeXB0by90cy90c19sY2wuaApAQCAtMTMxLDExICsxMzEsMzkgQEAgc3RydWN0 IEVTU19zaWduaW5nX2NlcnQgewogICAgIFNUQUNLX09GKFBPTElDWUlORk8pICpwb2xpY3lf aW5mbzsKIH07CiAKKy8qLQorICogRVNTQ2VydElEdjIgOjo9ICBTRVFVRU5DRSB7CisgKiAg ICAgICAgaGFzaEFsZ29yaXRobSAgICAgICAgICAgQWxnb3JpdGhtSWRlbnRpZmllcgorICog ICAgICAgICAgICAgICAgREVGQVVMVCB7YWxnb3JpdGhtIGlkLXNoYTI1Nn0sCisgKiAgICAg ICAgY2VydEhhc2ggICAgICAgICAgICAgICAgSGFzaCwKKyAqICAgICAgICBpc3N1ZXJTZXJp YWwgICAgICAgICAgICBJc3N1ZXJTZXJpYWwgT1BUSU9OQUwKKyAqIH0KKyAqLworCitzdHJ1 Y3QgRVNTX2NlcnRfaWRfdjJfc3QgeworICAgIFg1MDlfQUxHT1IgKmhhc2hfYWxnOyAgICAg ICAvKiBEZWZhdWx0OiBTSEEtMjU2ICovCisgICAgQVNOMV9PQ1RFVF9TVFJJTkcgKmhhc2g7 CisgICAgRVNTX0lTU1VFUl9TRVJJQUwgKmlzc3Vlcl9zZXJpYWw7Cit9OworCisvKi0KKyAq IFNpZ25pbmdDZXJ0aWZpY2F0ZVYyIDo6PSBTRVFVRU5DRSB7CisgKiAgICAgICAgY2VydHMg ICAgICAgICAgICAgICAgICAgU0VRVUVOQ0UgT0YgRVNTQ2VydElEdjIsCisgKiAgICAgICAg cG9saWNpZXMgICAgICAgICAgICAgICAgU0VRVUVOQ0UgT0YgUG9saWN5SW5mb3JtYXRpb24g T1BUSU9OQUwKKyAqIH0KKyAqLworCitzdHJ1Y3QgRVNTX3NpZ25pbmdfY2VydF92Ml9zdCB7 CisgICAgU1RBQ0tfT0YoRVNTX0NFUlRfSURfVjIpICpjZXJ0X2lkczsKKyAgICBTVEFDS19P RihQT0xJQ1lJTkZPKSAqcG9saWN5X2luZm87Cit9OworCiAKIHN0cnVjdCBUU19yZXNwX2N0 eCB7CiAgICAgWDUwOSAqc2lnbmVyX2NlcnQ7CiAgICAgRVZQX1BLRVkgKnNpZ25lcl9rZXk7 CiAgICAgY29uc3QgRVZQX01EICpzaWduZXJfbWQ7CisgICAgY29uc3QgRVZQX01EICplc3Nf Y2VydF9pZF9kaWdlc3Q7CiAgICAgU1RBQ0tfT0YoWDUwOSkgKmNlcnRzOyAgICAgIC8qIENl cnRzIHRvIGluY2x1ZGUgaW4gc2lnbmVkIGRhdGEuICovCiAgICAgU1RBQ0tfT0YoQVNOMV9P QkpFQ1QpICpwb2xpY2llczsgLyogQWNjZXB0YWJsZSBwb2xpY2llcy4gKi8KICAgICBBU04x X09CSkVDVCAqZGVmYXVsdF9wb2xpY3k7IC8qIEl0IG1heSBhcHBlYXIgaW4gcG9saWNpZXMs IHRvby4gKi8KZGlmZiAtLWdpdCBhL2NyeXB0by90cy90c19yc3Bfc2lnbi5jIGIvY3J5cHRv L3RzL3RzX3JzcF9zaWduLmMKaW5kZXggYWVhN2I5Mi4uNzYwMTFhZCAxMDA2NDQKLS0tIGEv Y3J5cHRvL3RzL3RzX3JzcF9zaWduLmMKKysrIGIvY3J5cHRvL3RzL3RzX3JzcF9zaWduLmMK QEAgLTM1LDcgKzM1LDE2IEBAIHN0YXRpYyBFU1NfU0lHTklOR19DRVJUICplc3NfU0lHTklO R19DRVJUX25ld19pbml0KFg1MDkgKnNpZ25jZXJ0LAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU1RBQ0tfT0YoWDUwOSkgKmNlcnRzKTsK IHN0YXRpYyBFU1NfQ0VSVF9JRCAqZXNzX0NFUlRfSURfbmV3X2luaXQoWDUwOSAqY2VydCwg aW50IGlzc3Vlcl9uZWVkZWQpOwogc3RhdGljIGludCB0c19UU1RfSU5GT19jb250ZW50X25l dyhQS0NTNyAqcDcpOwotc3RhdGljIGludCBFU1NfYWRkX3NpZ25pbmdfY2VydChQS0NTN19T SUdORVJfSU5GTyAqc2ksIEVTU19TSUdOSU5HX0NFUlQgKnNjKTsKK3N0YXRpYyBpbnQgZXNz X2FkZF9zaWduaW5nX2NlcnQoUEtDUzdfU0lHTkVSX0lORk8gKnNpLCBFU1NfU0lHTklOR19D RVJUICpzYyk7CisKK3N0YXRpYyBFU1NfU0lHTklOR19DRVJUX1YyICplc3Nfc2lnbmluZ19j ZXJ0X3YyX25ld19pbml0KGNvbnN0IEVWUF9NRCAqaGFzaF9hbGcsCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYNTA5ICpzaWdu Y2VydCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNUQUNLX09GKFg1MDkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqY2VydHMpOworc3RhdGljIEVTU19DRVJU X0lEX1YyICplc3NfY2VydF9pZF92Ml9uZXdfaW5pdChjb25zdCBFVlBfTUQgKmhhc2hfYWxn LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYNTA5 ICpjZXJ0LCBpbnQgaXNzdWVyX25lZWRlZCk7CitzdGF0aWMgaW50IGVzc19hZGRfc2lnbmlu Z19jZXJ0X3YyKFBLQ1M3X1NJR05FUl9JTkZPICpzaSwKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRVNTX1NJR05JTkdfQ0VSVF9WMiAqc2MpOwogCiBzdGF0aWMgQVNO MV9HRU5FUkFMSVpFRFRJTUUKICpUU19SRVNQX3NldF9nZW5UaW1lX3dpdGhfcHJlY2lzaW9u KEFTTjFfR0VORVJBTElaRURUSU1FICosIGxvbmcsIGxvbmcsCkBAIC02MjgsNiArNjM3LDcg QEAgc3RhdGljIGludCB0c19SRVNQX3NpZ24oVFNfUkVTUF9DVFggKmN0eCkKICAgICBQS0NT NyAqcDcgPSBOVUxMOwogICAgIFBLQ1M3X1NJR05FUl9JTkZPICpzaTsKICAgICBTVEFDS19P RihYNTA5KSAqY2VydHM7ICAgICAgLyogQ2VydGlmaWNhdGVzIHRvIGluY2x1ZGUgaW4gc2Mu ICovCisgICAgRVNTX1NJR05JTkdfQ0VSVF9WMiAqc2MyID0gTlVMTDsKICAgICBFU1NfU0lH TklOR19DRVJUICpzYyA9IE5VTEw7CiAgICAgQVNOMV9PQkpFQ1QgKm9pZDsKICAgICBCSU8g KnA3YmlvID0gTlVMTDsKQEAgLTY3MSwxMSArNjgxLDI0IEBAIHN0YXRpYyBpbnQgdHNfUkVT UF9zaWduKFRTX1JFU1BfQ1RYICpjdHgpCiAgICAgfQogCiAgICAgY2VydHMgPSBjdHgtPmZs YWdzICYgVFNfRVNTX0NFUlRfSURfQ0hBSU4gPyBjdHgtPmNlcnRzIDogTlVMTDsKLSAgICBp ZiAoKHNjID0gZXNzX1NJR05JTkdfQ0VSVF9uZXdfaW5pdChjdHgtPnNpZ25lcl9jZXJ0LCBj ZXJ0cykpID09IE5VTEwpCi0gICAgICAgIGdvdG8gZXJyOwotICAgIGlmICghRVNTX2FkZF9z aWduaW5nX2NlcnQoc2ksIHNjKSkgewotICAgICAgICBUU2VycihUU19GX1RTX1JFU1BfU0lH TiwgVFNfUl9FU1NfQUREX1NJR05JTkdfQ0VSVF9FUlJPUik7Ci0gICAgICAgIGdvdG8gZXJy OworICAgIGlmIChjdHgtPmVzc19jZXJ0X2lkX2RpZ2VzdCA9PSBFVlBfc2hhMSgpKSB7Cisg ICAgICAgIGlmICgoc2MgPSBlc3NfU0lHTklOR19DRVJUX25ld19pbml0KGN0eC0+c2lnbmVy X2NlcnQsIGNlcnRzKSkgPT0gTlVMTCkKKyAgICAgICAgICAgIGdvdG8gZXJyOworCisgICAg ICAgIGlmICghZXNzX2FkZF9zaWduaW5nX2NlcnQoc2ksIHNjKSkgeworICAgICAgICAgICAg VFNlcnIoVFNfRl9UU19SRVNQX1NJR04sIFRTX1JfRVNTX0FERF9TSUdOSU5HX0NFUlRfRVJS T1IpOworICAgICAgICAgICAgZ290byBlcnI7CisgICAgICAgIH0KKyAgICB9IGVsc2Ugewor ICAgICAgICBzYzIgPSBlc3Nfc2lnbmluZ19jZXJ0X3YyX25ld19pbml0KGN0eC0+ZXNzX2Nl cnRfaWRfZGlnZXN0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGN0eC0+c2lnbmVyX2NlcnQsIGNlcnRzKTsKKyAgICAgICAgaWYgKHNjMiA9PSBOVUxM KQorICAgICAgICAgICAgZ290byBlcnI7CisKKyAgICAgICAgaWYgKCFlc3NfYWRkX3NpZ25p bmdfY2VydF92MihzaSwgc2MyKSkgeworICAgICAgICAgICAgVFNlcnIoVFNfRl9UU19SRVNQ X1NJR04sIFRTX1JfRVNTX0FERF9TSUdOSU5HX0NFUlRfVjJfRVJST1IpOworICAgICAgICAg ICAgZ290byBlcnI7CisgICAgICAgIH0KICAgICB9CiAKICAgICBpZiAoIXRzX1RTVF9JTkZP X2NvbnRlbnRfbmV3KHA3KSkKQEAgLTcwMyw2ICs3MjYsNyBAQCBzdGF0aWMgaW50IHRzX1JF U1Bfc2lnbihUU19SRVNQX0NUWCAqY3R4KQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAiRXJyb3IgZHVyaW5nIHNpZ25hdHVyZSAiCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJnZW5lcmF0aW9uLiIpOwogICAgIEJJT19m cmVlX2FsbChwN2Jpbyk7CisgICAgRVNTX1NJR05JTkdfQ0VSVF9WMl9mcmVlKHNjMik7CiAg ICAgRVNTX1NJR05JTkdfQ0VSVF9mcmVlKHNjKTsKICAgICBQS0NTN19mcmVlKHA3KTsKICAg ICByZXR1cm4gcmV0OwpAQCAtODA2LDcgKzgzMCw3IEBAIHN0YXRpYyBpbnQgdHNfVFNUX0lO Rk9fY29udGVudF9uZXcoUEtDUzcgKnA3KQogICAgIHJldHVybiAwOwogfQogCi1zdGF0aWMg aW50IEVTU19hZGRfc2lnbmluZ19jZXJ0KFBLQ1M3X1NJR05FUl9JTkZPICpzaSwgRVNTX1NJ R05JTkdfQ0VSVCAqc2MpCitzdGF0aWMgaW50IGVzc19hZGRfc2lnbmluZ19jZXJ0KFBLQ1M3 X1NJR05FUl9JTkZPICpzaSwgRVNTX1NJR05JTkdfQ0VSVCAqc2MpCiB7CiAgICAgQVNOMV9T VFJJTkcgKnNlcSA9IE5VTEw7CiAgICAgdW5zaWduZWQgY2hhciAqcCwgKnBwID0gTlVMTDsK QEAgLTgzNSw5ICs4NTksMTMzIEBAIHN0YXRpYyBpbnQgRVNTX2FkZF9zaWduaW5nX2NlcnQo UEtDUzdfU0lHTkVSX0lORk8gKnNpLCBFU1NfU0lHTklOR19DRVJUICpzYykKICAgICByZXR1 cm4gMDsKIH0KIAotc3RhdGljIEFTTjFfR0VORVJBTElaRURUSU1FCi0qVFNfUkVTUF9zZXRf Z2VuVGltZV93aXRoX3ByZWNpc2lvbihBU04xX0dFTkVSQUxJWkVEVElNRSAqYXNuMV90aW1l LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9uZyBzZWMsIGxvbmcg dXNlYywgdW5zaWduZWQgcHJlY2lzaW9uKQorc3RhdGljIEVTU19TSUdOSU5HX0NFUlRfVjIg KmVzc19zaWduaW5nX2NlcnRfdjJfbmV3X2luaXQoY29uc3QgRVZQX01EICpoYXNoX2FsZywK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFg1MDkgKnNpZ25jZXJ0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU1RBQ0tfT0YoWDUwOSkgKmNlcnRzKQoreworICAg IEVTU19DRVJUX0lEX1YyICpjaWQgPSBOVUxMOworICAgIEVTU19TSUdOSU5HX0NFUlRfVjIg KnNjID0gTlVMTDsKKyAgICBpbnQgaTsKKworICAgIGlmICgoc2MgPSBFU1NfU0lHTklOR19D RVJUX1YyX25ldygpKSA9PSBOVUxMKQorICAgICAgICBnb3RvIGVycjsKKyAgICBpZiAoKGNp ZCA9IGVzc19jZXJ0X2lkX3YyX25ld19pbml0KGhhc2hfYWxnLCBzaWduY2VydCwgMCkpID09 IE5VTEwpCisgICAgICAgIGdvdG8gZXJyOworICAgIGlmICghc2tfRVNTX0NFUlRfSURfVjJf cHVzaChzYy0+Y2VydF9pZHMsIGNpZCkpCisgICAgICAgIGdvdG8gZXJyOworICAgIGNpZCA9 IE5VTEw7CisKKyAgICBmb3IgKGkgPSAwOyBpIDwgc2tfWDUwOV9udW0oY2VydHMpOyArK2kp IHsKKyAgICAgICAgWDUwOSAqY2VydCA9IHNrX1g1MDlfdmFsdWUoY2VydHMsIGkpOworCisg ICAgICAgIGlmICgoY2lkID0gZXNzX2NlcnRfaWRfdjJfbmV3X2luaXQoaGFzaF9hbGcsIGNl cnQsIDEpKSA9PSBOVUxMKQorICAgICAgICAgICAgZ290byBlcnI7CisgICAgICAgIGlmICgh c2tfRVNTX0NFUlRfSURfVjJfcHVzaChzYy0+Y2VydF9pZHMsIGNpZCkpCisgICAgICAgICAg ICBnb3RvIGVycjsKKyAgICAgICAgY2lkID0gTlVMTDsKKyAgICB9CisKKyAgICByZXR1cm4g c2M7CisgZXJyOgorICAgIEVTU19TSUdOSU5HX0NFUlRfVjJfZnJlZShzYyk7CisgICAgRVNT X0NFUlRfSURfVjJfZnJlZShjaWQpOworICAgIFRTZXJyKFRTX0ZfRVNTX1NJR05JTkdfQ0VS VF9WMl9ORVdfSU5JVCwgRVJSX1JfTUFMTE9DX0ZBSUxVUkUpOworICAgIHJldHVybiBOVUxM OworfQorCitzdGF0aWMgRVNTX0NFUlRfSURfVjIgKmVzc19jZXJ0X2lkX3YyX25ld19pbml0 KGNvbnN0IEVWUF9NRCAqaGFzaF9hbGcsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFg1MDkgKmNlcnQsIGludCBpc3N1ZXJfbmVlZGVkKQorewor ICAgIEVTU19DRVJUX0lEX1YyICpjaWQgPSBOVUxMOworICAgIEdFTkVSQUxfTkFNRSAqbmFt ZSA9IE5VTEw7CisgICAgdW5zaWduZWQgY2hhciBoYXNoW0VWUF9NQVhfTURfU0laRV07Cisg ICAgdW5zaWduZWQgaW50IGhhc2hfbGVuID0gc2l6ZW9mKGhhc2gpOworICAgIFg1MDlfQUxH T1IgKmFsZyA9IE5VTEw7CisKKyAgICBtZW1zZXQoaGFzaCwgMCwgc2l6ZW9mKGhhc2gpKTsK KworICAgIGlmICgoY2lkID0gRVNTX0NFUlRfSURfVjJfbmV3KCkpID09IE5VTEwpCisgICAg ICAgIGdvdG8gZXJyOworCisgICAgaWYgKGhhc2hfYWxnICE9IEVWUF9zaGEyNTYoKSkgewor ICAgICAgICBhbGcgPSBYNTA5X0FMR09SX25ldygpOworICAgICAgICBpZiAoYWxnID09IE5V TEwpCisgICAgICAgICAgICBnb3RvIGVycjsKKyAgICAgICAgWDUwOV9BTEdPUl9zZXRfbWQo YWxnLCBoYXNoX2FsZyk7CisgICAgICAgIGlmIChhbGctPmFsZ29yaXRobSA9PSBOVUxMKQor ICAgICAgICAgICAgZ290byBlcnI7CisgICAgICAgIGNpZC0+aGFzaF9hbGcgPSBhbGc7Cisg ICAgICAgIGFsZyA9IE5VTEw7CisgICAgfSBlbHNlIHsKKyAgICAgICAgY2lkLT5oYXNoX2Fs ZyA9IE5VTEw7CisgICAgfQorCisgICAgaWYgKCFYNTA5X2RpZ2VzdChjZXJ0LCBoYXNoX2Fs ZywgaGFzaCwgJmhhc2hfbGVuKSkKKyAgICAgICAgZ290byBlcnI7CisKKyAgICBpZiAoIUFT TjFfT0NURVRfU1RSSU5HX3NldChjaWQtPmhhc2gsIGhhc2gsIGhhc2hfbGVuKSkKKyAgICAg ICAgZ290byBlcnI7CisKKyAgICBpZiAoaXNzdWVyX25lZWRlZCkgeworICAgICAgICBpZiAo KGNpZC0+aXNzdWVyX3NlcmlhbCA9IEVTU19JU1NVRVJfU0VSSUFMX25ldygpKSA9PSBOVUxM KQorICAgICAgICAgICAgZ290byBlcnI7CisgICAgICAgIGlmICgobmFtZSA9IEdFTkVSQUxf TkFNRV9uZXcoKSkgPT0gTlVMTCkKKyAgICAgICAgICAgIGdvdG8gZXJyOworICAgICAgICBu YW1lLT50eXBlID0gR0VOX0RJUk5BTUU7CisgICAgICAgIGlmICgobmFtZS0+ZC5kaXJuID0g WDUwOV9OQU1FX2R1cChYNTA5X2dldF9pc3N1ZXJfbmFtZShjZXJ0KSkpID09IE5VTEwpCisg ICAgICAgICAgICBnb3RvIGVycjsKKyAgICAgICAgaWYgKCFza19HRU5FUkFMX05BTUVfcHVz aChjaWQtPmlzc3Vlcl9zZXJpYWwtPmlzc3VlciwgbmFtZSkpCisgICAgICAgICAgICBnb3Rv IGVycjsKKyAgICAgICAgbmFtZSA9IE5VTEw7ICAgICAgICAgICAgLyogT3duZXJzaGlwIGlz IGxvc3QuICovCisgICAgICAgIEFTTjFfSU5URUdFUl9mcmVlKGNpZC0+aXNzdWVyX3Nlcmlh bC0+c2VyaWFsKTsKKyAgICAgICAgY2lkLT5pc3N1ZXJfc2VyaWFsLT5zZXJpYWwgPQorICAg ICAgICAgICAgICAgIEFTTjFfSU5URUdFUl9kdXAoWDUwOV9nZXRfc2VyaWFsTnVtYmVyKGNl cnQpKTsKKyAgICAgICAgaWYgKGNpZC0+aXNzdWVyX3NlcmlhbC0+c2VyaWFsID09IE5VTEwp CisgICAgICAgICAgICBnb3RvIGVycjsKKyAgICB9CisKKyAgICByZXR1cm4gY2lkOworIGVy cjoKKyAgICBYNTA5X0FMR09SX2ZyZWUoYWxnKTsKKyAgICBHRU5FUkFMX05BTUVfZnJlZShu YW1lKTsKKyAgICBFU1NfQ0VSVF9JRF9WMl9mcmVlKGNpZCk7CisgICAgVFNlcnIoVFNfRl9F U1NfQ0VSVF9JRF9WMl9ORVdfSU5JVCwgRVJSX1JfTUFMTE9DX0ZBSUxVUkUpOworICAgIHJl dHVybiBOVUxMOworfQorCitzdGF0aWMgaW50IGVzc19hZGRfc2lnbmluZ19jZXJ0X3YyKFBL Q1M3X1NJR05FUl9JTkZPICpzaSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRVNTX1NJR05JTkdfQ0VSVF9WMiAqc2MpCit7CisgICAgQVNOMV9TVFJJTkcgKnNlcSA9 IE5VTEw7CisgICAgdW5zaWduZWQgY2hhciAqcCwgKnBwID0gTlVMTDsKKyAgICBpbnQgbGVu ID0gaTJkX0VTU19TSUdOSU5HX0NFUlRfVjIoc2MsIE5VTEwpOworCisgICAgaWYgKChwcCA9 IE9QRU5TU0xfbWFsbG9jKGxlbikpID09IE5VTEwpIHsKKyAgICAgICAgVFNlcnIoVFNfRl9F U1NfQUREX1NJR05JTkdfQ0VSVF9WMiwgRVJSX1JfTUFMTE9DX0ZBSUxVUkUpOworICAgICAg ICBnb3RvIGVycjsKKyAgICB9CisKKyAgICBwID0gcHA7CisgICAgaTJkX0VTU19TSUdOSU5H X0NFUlRfVjIoc2MsICZwKTsKKyAgICBpZiAoKHNlcSA9IEFTTjFfU1RSSU5HX25ldygpKSA9 PSBOVUxMIHx8ICFBU04xX1NUUklOR19zZXQoc2VxLCBwcCwgbGVuKSkgeworICAgICAgICBU U2VycihUU19GX0VTU19BRERfU0lHTklOR19DRVJUX1YyLCBFUlJfUl9NQUxMT0NfRkFJTFVS RSk7CisgICAgICAgIGdvdG8gZXJyOworICAgIH0KKworICAgIE9QRU5TU0xfZnJlZShwcCk7 CisgICAgcHAgPSBOVUxMOworICAgIHJldHVybiBQS0NTN19hZGRfc2lnbmVkX2F0dHJpYnV0 ZShzaSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklEX2lkX3Nt aW1lX2FhX3NpZ25pbmdDZXJ0aWZpY2F0ZVYyLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBWX0FTTjFfU0VRVUVOQ0UsIHNlcSk7CisgZXJyOgorICAgIEFTTjFf U1RSSU5HX2ZyZWUoc2VxKTsKKyAgICBPUEVOU1NMX2ZyZWUocHApOworICAgIHJldHVybiAw OworfQorCitzdGF0aWMgQVNOMV9HRU5FUkFMSVpFRFRJTUUgKlRTX1JFU1Bfc2V0X2dlblRp bWVfd2l0aF9wcmVjaXNpb24oCisgICAgICAgIEFTTjFfR0VORVJBTElaRURUSU1FICphc24x X3RpbWUsIGxvbmcgc2VjLCBsb25nIHVzZWMsCisgICAgICAgIHVuc2lnbmVkIHByZWNpc2lv bikKIHsKICAgICB0aW1lX3QgdGltZV9zZWMgPSAodGltZV90KXNlYzsKICAgICBzdHJ1Y3Qg dG0gKnRtID0gTlVMTDsKQEAgLTkwMiwzICsxMDUwLDkgQEAgc3RhdGljIEFTTjFfR0VORVJB TElaRURUSU1FCiAgICAgVFNlcnIoVFNfRl9UU19SRVNQX1NFVF9HRU5USU1FX1dJVEhfUFJF Q0lTSU9OLCBUU19SX0NPVUxEX05PVF9TRVRfVElNRSk7CiAgICAgcmV0dXJuIE5VTEw7CiB9 CisKK2ludCBUU19SRVNQX0NUWF9zZXRfZXNzX2NlcnRfaWRfZGlnZXN0KFRTX1JFU1BfQ1RY ICpjdHgsIGNvbnN0IEVWUF9NRCAqbWQpCit7CisgICAgY3R4LT5lc3NfY2VydF9pZF9kaWdl c3QgPSBtZDsKKyAgICByZXR1cm4gMTsKK30KZGlmZiAtLWdpdCBhL2NyeXB0by90cy90c19y c3BfdmVyaWZ5LmMgYi9jcnlwdG8vdHMvdHNfcnNwX3ZlcmlmeS5jCmluZGV4IDY2ZjViZTYu LjlkZWRhODEgMTAwNjQ0Ci0tLSBhL2NyeXB0by90cy90c19yc3BfdmVyaWZ5LmMKKysrIGIv Y3J5cHRvL3RzL3RzX3JzcF92ZXJpZnkuYwpAQCAtMzcsNiArMzcsOCBAQCBzdGF0aWMgaW50 IHRzX2NoZWNrX25vbmNlcyhjb25zdCBBU04xX0lOVEVHRVIgKmEsIFRTX1RTVF9JTkZPICp0 c3RfaW5mbyk7CiBzdGF0aWMgaW50IHRzX2NoZWNrX3NpZ25lcl9uYW1lKEdFTkVSQUxfTkFN RSAqdHNhX25hbWUsIFg1MDkgKnNpZ25lcik7CiBzdGF0aWMgaW50IHRzX2ZpbmRfbmFtZShT VEFDS19PRihHRU5FUkFMX05BTUUpICpnZW5fbmFtZXMsCiAgICAgICAgICAgICAgICAgICAg ICAgICBHRU5FUkFMX05BTUUgKm5hbWUpOworc3RhdGljIGludCB0c19maW5kX2NlcnRfdjIo U1RBQ0tfT0YoRVNTX0NFUlRfSURfVjIpICpjZXJ0X2lkcywgWDUwOSAqY2VydCk7CitzdGF0 aWMgRVNTX1NJR05JTkdfQ0VSVF9WMiAqZXNzX2dldF9zaWduaW5nX2NlcnRfdjIoUEtDUzdf U0lHTkVSX0lORk8gKnNpKTsKIAogLyoKICAqIFRoaXMgbXVzdCBiZSBsYXJnZSBlbm91Z2gg dG8gaG9sZCBhbGwgdmFsdWVzIGluIHRzX3N0YXR1c190ZXh0ICh3aXRoCkBAIC0yMDEsMzQg KzIwMyw1NyBAQCBzdGF0aWMgaW50IHRzX2NoZWNrX3NpZ25pbmdfY2VydHMoUEtDUzdfU0lH TkVSX0lORk8gKnNpLAogewogICAgIEVTU19TSUdOSU5HX0NFUlQgKnNzID0gZXNzX2dldF9z aWduaW5nX2NlcnQoc2kpOwogICAgIFNUQUNLX09GKEVTU19DRVJUX0lEKSAqY2VydF9pZHMg PSBOVUxMOworICAgIEVTU19TSUdOSU5HX0NFUlRfVjIgKnNzdjIgPSBlc3NfZ2V0X3NpZ25p bmdfY2VydF92MihzaSk7CisgICAgU1RBQ0tfT0YoRVNTX0NFUlRfSURfVjIpICpjZXJ0X2lk c192MiA9IE5VTEw7CiAgICAgWDUwOSAqY2VydDsKICAgICBpbnQgaSA9IDA7CiAgICAgaW50 IHJldCA9IDA7CiAKLSAgICBpZiAoIXNzKQotICAgICAgICBnb3RvIGVycjsKLSAgICBjZXJ0 X2lkcyA9IHNzLT5jZXJ0X2lkczsKLSAgICBjZXJ0ID0gc2tfWDUwOV92YWx1ZShjaGFpbiwg MCk7Ci0gICAgaWYgKHRzX2ZpbmRfY2VydChjZXJ0X2lkcywgY2VydCkgIT0gMCkKLSAgICAg ICAgZ290byBlcnI7CisgICAgaWYgKHNzICE9IE5VTEwpIHsKKyAgICAgICAgY2VydF9pZHMg PSBzcy0+Y2VydF9pZHM7CisgICAgICAgIGNlcnQgPSBza19YNTA5X3ZhbHVlKGNoYWluLCAw KTsKKyAgICAgICAgaWYgKHRzX2ZpbmRfY2VydChjZXJ0X2lkcywgY2VydCkgIT0gMCkKKyAg ICAgICAgICAgIGdvdG8gZXJyOwogCi0gICAgLyoKLSAgICAgKiBDaGVjayB0aGUgb3RoZXIg Y2VydGlmaWNhdGVzIG9mIHRoZSBjaGFpbiBpZiB0aGVyZSBhcmUgbW9yZSB0aGFuIG9uZQot ICAgICAqIGNlcnRpZmljYXRlIGlkcyBpbiBjZXJ0X2lkcy4KLSAgICAgKi8KLSAgICBpZiAo c2tfRVNTX0NFUlRfSURfbnVtKGNlcnRfaWRzKSA+IDEpIHsKLSAgICAgICAgZm9yIChpID0g MTsgaSA8IHNrX1g1MDlfbnVtKGNoYWluKTsgKytpKSB7Ci0gICAgICAgICAgICBjZXJ0ID0g c2tfWDUwOV92YWx1ZShjaGFpbiwgaSk7Ci0gICAgICAgICAgICBpZiAodHNfZmluZF9jZXJ0 KGNlcnRfaWRzLCBjZXJ0KSA8IDApCi0gICAgICAgICAgICAgICAgZ290byBlcnI7CisgICAg ICAgIC8qCisgICAgICAgICAqIENoZWNrIHRoZSBvdGhlciBjZXJ0aWZpY2F0ZXMgb2YgdGhl IGNoYWluIGlmIHRoZXJlIGFyZSBtb3JlIHRoYW4gb25lCisgICAgICAgICAqIGNlcnRpZmlj YXRlIGlkcyBpbiBjZXJ0X2lkcy4KKyAgICAgICAgICovCisgICAgICAgIGlmIChza19FU1Nf Q0VSVF9JRF9udW0oY2VydF9pZHMpID4gMSkgeworICAgICAgICAgICAgZm9yIChpID0gMTsg aSA8IHNrX1g1MDlfbnVtKGNoYWluKTsgKytpKSB7CisgICAgICAgICAgICAgICAgY2VydCA9 IHNrX1g1MDlfdmFsdWUoY2hhaW4sIGkpOworICAgICAgICAgICAgICAgIGlmICh0c19maW5k X2NlcnQoY2VydF9pZHMsIGNlcnQpIDwgMCkKKyAgICAgICAgICAgICAgICAgICAgZ290byBl cnI7CisgICAgICAgICAgICB9CiAgICAgICAgIH0KKyAgICB9IGVsc2UgaWYgKHNzdjIgIT0g TlVMTCkgeworICAgICAgICBjZXJ0X2lkc192MiA9IHNzdjItPmNlcnRfaWRzOworICAgICAg ICBjZXJ0ID0gc2tfWDUwOV92YWx1ZShjaGFpbiwgMCk7CisgICAgICAgIGlmICh0c19maW5k X2NlcnRfdjIoY2VydF9pZHNfdjIsIGNlcnQpICE9IDApCisgICAgICAgICAgICBnb3RvIGVy cjsKKworICAgICAgICAvKgorICAgICAgICAgKiBDaGVjayB0aGUgb3RoZXIgY2VydGlmaWNh dGVzIG9mIHRoZSBjaGFpbiBpZiB0aGVyZSBhcmUgbW9yZSB0aGFuIG9uZQorICAgICAgICAg KiBjZXJ0aWZpY2F0ZSBpZHMgaW4gY2VydF9pZHMuCisgICAgICAgICAqLworICAgICAgICBp ZiAoc2tfRVNTX0NFUlRfSURfVjJfbnVtKGNlcnRfaWRzX3YyKSA+IDEpIHsKKyAgICAgICAg ICAgIGZvciAoaSA9IDE7IGkgPCBza19YNTA5X251bShjaGFpbik7ICsraSkgeworICAgICAg ICAgICAgICAgIGNlcnQgPSBza19YNTA5X3ZhbHVlKGNoYWluLCBpKTsKKyAgICAgICAgICAg ICAgICBpZiAodHNfZmluZF9jZXJ0X3YyKGNlcnRfaWRzX3YyLCBjZXJ0KSA8IDApCisgICAg ICAgICAgICAgICAgICAgIGdvdG8gZXJyOworICAgICAgICAgICAgfQorICAgICAgICB9Cisg ICAgfSBlbHNlIHsKKyAgICAgICAgZ290byBlcnI7CiAgICAgfQorCiAgICAgcmV0ID0gMTsK ICBlcnI6CiAgICAgaWYgKCFyZXQpCiAgICAgICAgIFRTZXJyKFRTX0ZfVFNfQ0hFQ0tfU0lH TklOR19DRVJUUywKICAgICAgICAgICAgICAgVFNfUl9FU1NfU0lHTklOR19DRVJUSUZJQ0FU RV9FUlJPUik7CiAgICAgRVNTX1NJR05JTkdfQ0VSVF9mcmVlKHNzKTsKKyAgICBFU1NfU0lH TklOR19DRVJUX1YyX2ZyZWUoc3N2Mik7CiAgICAgcmV0dXJuIHJldDsKIH0KIApAQCAtMjQz LDYgKzI2OCwxOCBAQCBzdGF0aWMgRVNTX1NJR05JTkdfQ0VSVCAqZXNzX2dldF9zaWduaW5n X2NlcnQoUEtDUzdfU0lHTkVSX0lORk8gKnNpKQogICAgIHJldHVybiBkMmlfRVNTX1NJR05J TkdfQ0VSVChOVUxMLCAmcCwgYXR0ci0+dmFsdWUuc2VxdWVuY2UtPmxlbmd0aCk7CiB9CiAK K3N0YXRpYyBFU1NfU0lHTklOR19DRVJUX1YyICplc3NfZ2V0X3NpZ25pbmdfY2VydF92MihQ S0NTN19TSUdORVJfSU5GTyAqc2kpCit7CisgICAgQVNOMV9UWVBFICphdHRyOworICAgIGNv bnN0IHVuc2lnbmVkIGNoYXIgKnA7CisKKyAgICBhdHRyID0gUEtDUzdfZ2V0X3NpZ25lZF9h dHRyaWJ1dGUoc2ksIE5JRF9pZF9zbWltZV9hYV9zaWduaW5nQ2VydGlmaWNhdGVWMik7Cisg ICAgaWYgKGF0dHIgPT0gTlVMTCkKKyAgICAgICAgcmV0dXJuIE5VTEw7CisgICAgcCA9IGF0 dHItPnZhbHVlLnNlcXVlbmNlLT5kYXRhOworICAgIHJldHVybiBkMmlfRVNTX1NJR05JTkdf Q0VSVF9WMihOVUxMLCAmcCwgYXR0ci0+dmFsdWUuc2VxdWVuY2UtPmxlbmd0aCk7Cit9CisK IC8qIFJldHVybnMgPCAwIGlmIGNlcnRpZmljYXRlIGlzIG5vdCBmb3VuZCwgY2VydGlmaWNh dGUgaW5kZXggb3RoZXJ3aXNlLiAqLwogc3RhdGljIGludCB0c19maW5kX2NlcnQoU1RBQ0tf T0YoRVNTX0NFUlRfSUQpICpjZXJ0X2lkcywgWDUwOSAqY2VydCkKIHsKQEAgLTI3Miw2ICsz MDksMzggQEAgc3RhdGljIGludCB0c19maW5kX2NlcnQoU1RBQ0tfT0YoRVNTX0NFUlRfSUQp ICpjZXJ0X2lkcywgWDUwOSAqY2VydCkKICAgICByZXR1cm4gLTE7CiB9CiAKKy8qIFJldHVy bnMgPCAwIGlmIGNlcnRpZmljYXRlIGlzIG5vdCBmb3VuZCwgY2VydGlmaWNhdGUgaW5kZXgg b3RoZXJ3aXNlLiAqLworc3RhdGljIGludCB0c19maW5kX2NlcnRfdjIoU1RBQ0tfT0YoRVNT X0NFUlRfSURfVjIpICpjZXJ0X2lkcywgWDUwOSAqY2VydCkKK3sKKyAgICBpbnQgaTsKKyAg ICB1bnNpZ25lZCBjaGFyIGNlcnRfZGlnZXN0W0VWUF9NQVhfTURfU0laRV07CisgICAgdW5z aWduZWQgaW50IGxlbjsKKworICAgIC8qIExvb2sgZm9yIGNlcnQgaW4gdGhlIGNlcnRfaWRz IHZlY3Rvci4gKi8KKyAgICBmb3IgKGkgPSAwOyBpIDwgc2tfRVNTX0NFUlRfSURfVjJfbnVt KGNlcnRfaWRzKTsgKytpKSB7CisgICAgICAgIEVTU19DRVJUX0lEX1YyICpjaWQgPSBza19F U1NfQ0VSVF9JRF9WMl92YWx1ZShjZXJ0X2lkcywgaSk7CisgICAgICAgIGNvbnN0IEVWUF9N RCAqbWQ7CisKKyAgICAgICAgaWYgKGNpZC0+aGFzaF9hbGcgIT0gTlVMTCkKKyAgICAgICAg ICAgIG1kID0gRVZQX2dldF9kaWdlc3RieW9iaihjaWQtPmhhc2hfYWxnLT5hbGdvcml0aG0p OworICAgICAgICBlbHNlCisgICAgICAgICAgICBtZCA9IEVWUF9zaGEyNTYoKTsKKworICAg ICAgICBYNTA5X2RpZ2VzdChjZXJ0LCBtZCwgY2VydF9kaWdlc3QsICZsZW4pOworICAgICAg ICBpZiAoY2lkLT5oYXNoLT5sZW5ndGggIT0gKGludClsZW4pCisgICAgICAgICAgICByZXR1 cm4gLTE7CisKKyAgICAgICAgaWYgKG1lbWNtcChjaWQtPmhhc2gtPmRhdGEsIGNlcnRfZGln ZXN0LCBjaWQtPmhhc2gtPmxlbmd0aCkgPT0gMCkgeworICAgICAgICAgICAgRVNTX0lTU1VF Ul9TRVJJQUwgKmlzID0gY2lkLT5pc3N1ZXJfc2VyaWFsOworCisgICAgICAgICAgICBpZiAo aXMgPT0gTlVMTCB8fCAhdHNfaXNzdWVyX3NlcmlhbF9jbXAoaXMsIGNlcnQpKQorICAgICAg ICAgICAgICAgIHJldHVybiBpOworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIC0x OworfQorCiBzdGF0aWMgaW50IHRzX2lzc3Vlcl9zZXJpYWxfY21wKEVTU19JU1NVRVJfU0VS SUFMICppcywgWDUwOSAqY2VydCkKIHsKICAgICBHRU5FUkFMX05BTUUgKmlzc3VlcjsKZGlm ZiAtLWdpdCBhL2RvYy9tYW4xL3RzLnBvZCBiL2RvYy9tYW4xL3RzLnBvZAppbmRleCAyZWM5 ODM3Li5kNDY5YjIzIDEwMDY0NAotLS0gYS9kb2MvbWFuMS90cy5wb2QKKysrIGIvZG9jL21h bjEvdHMucG9kCkBAIC01MDMsNiArNTAzLDExIEBAIGJlIGluY2x1ZGVkIGluIHRoZSBTaWdu aW5nQ2VydGlmaWNhdGUgc2lnbmVkIGF0dHJpYnV0ZS4gSWYgdGhpcwogdmFyaWFibGUgaXMg c2V0IHRvIG5vLCBvbmx5IHRoZSBzaWduaW5nIGNlcnRpZmljYXRlIGlkZW50aWZpZXIgaXMK IGluY2x1ZGVkLiBEZWZhdWx0IGlzIG5vLiAoT3B0aW9uYWwpCiAKKz1pdGVtIEI8ZXNzX2Nl cnRfaWRfYWxnPgorCitUaGlzIG9wdGlvbiBzcGVjaWZpZXMgdGhlIGhhc2ggZnVuY3Rpb24g dG8gYmUgdXNlZCB0byBjYWxjdWxhdGUgdGhlIFRTQSdzCitwdWJsaWMga2V5IGNlcnRpZmlj YXRlIGlkZW50aWZpZXIuIERlZmF1bHQgaXMgc2hhMS4gKE9wdGlvbmFsKQorCiA9YmFjawog CiA9aGVhZDEgRVhBTVBMRVMKQEAgLTYwNSw5ICs2MTAsNiBAQCBZb3UgY291bGQgYWxzbyBs b29rIGF0IHRoZSAndGVzdCcgZGlyZWN0b3J5IGZvciBtb3JlIGV4YW1wbGVzLgogCiA9Zm9y IGNvbW1lbnQgZm9yZWlnbiBtYW51YWxzOiBwcm9jbWFpbCgxKSwgcGVybCgxKQogCi1JZiB5 b3UgZmluZCBhbnkgYnVncyBvciB5b3UgaGF2ZSBzdWdnZXN0aW9ucyBwbGVhc2Ugd3JpdGUg dG8KLVpvbHRhbiBHbG96aWsgPHpnbG96aWtAb3BlbnRzYS5vcmc+LiBLbm93biBpc3N1ZXM6 Ci0KID1vdmVyIDIKIAogPWl0ZW0gKgpkaWZmIC0tZ2l0IGEvZG9jL21hbjMvU1NMX0NPTkZf Y21kLnBvZCBiL2RvYy9tYW4zL1NTTF9DT05GX2NtZC5wb2QKaW5kZXggZWZkNzY2ZC4uNjcz MWNmNyAxMDA2NDQKLS0tIGEvZG9jL21hbjMvU1NMX0NPTkZfY21kLnBvZAorKysgYi9kb2Mv bWFuMy9TU0xfQ09ORl9jbWQucG9kCkBAIC03Myw2ICs3MywyNiBAQCBUaGUgQjx2YWx1ZT4g YXJndW1lbnQgaXMgYSBjb2xvbiBzZXBhcmF0ZWQgbGlzdCBvZiBjdXJ2ZXMuIFRoZSBjdXJ2 ZSBjYW4gYmUKIGVpdGhlciB0aGUgQjxOSVNUPiBuYW1lIChlLmcuIEI8UC0yNTY+KSBvciBh biBPcGVuU1NMIE9JRCBuYW1lIChlLmcKIEI8cHJpbWUyNTZ2MT4pLiBDdXJ2ZSBuYW1lcyBh cmUgY2FzZSBzZW5zaXRpdmUuCiAKKz1pdGVtIEI8LWdyb3Vwcz4KKworVGhpcyBzZXRzIHRo ZSBzdXBwb3J0ZWQgZ3JvdXBzLiBGb3IgY2xpZW50cywgdGhlIGdyb3VwcyBhcmUKK3NlbnQg dXNpbmcgdGhlIHN1cHBvcnRlZCBncm91cHMgZXh0ZW5zaW9uLiBGb3Igc2VydmVycywgaXQg aXMgdXNlZAordG8gZGV0ZXJtaW5lIHdoaWNoIGdyb3VwIHRvIHVzZS4gVGhpcyBzZXR0aW5n IGFmZmVjdHMgZ3JvdXBzIHVzZWQgZm9yIGJvdGgKK3NpZ25hdHVyZXMgYW5kIGtleSBleGNo YW5nZSwgaWYgYXBwbGljYWJsZS4gSXQgYWxzbyBhZmZlY3RzIHRoZSBwcmVmZXJyZWQKK2tl eV9zaGFyZSBzZW50IGJ5IGEgY2xpZW50IGluIGEgVExTdjEuMyBjb21wYXRpYmxlIGNvbm5l Y3Rpb24uCisKK1RoZSBCPHZhbHVlPiBhcmd1bWVudCBpcyBhIGNvbG9uIHNlcGFyYXRlZCBs aXN0IG9mIGdyb3Vwcy4gVGhlIGdyb3VwIGNhbiBiZQorZWl0aGVyIHRoZSBCPE5JU1Q+IG5h bWUgKGUuZy4gQjxQLTI1Nj4pLCBzb21lIG90aGVyIGNvbW1vbmx5IHVzZWQgbmFtZSB3aGVy ZQorYXBwbGljYWJsZSAoZS5nLiBCPFgyNTUxOT4pIG9yIGFuIE9wZW5TU0wgT0lEIG5hbWUg KGUuZyBCPHByaW1lMjU2djE+KS4gR3JvdXAKK25hbWVzIGFyZSBjYXNlIHNlbnNpdGl2ZS4g VGhlIGxpc3Qgc2hvdWxkIGJlIGluIG9yZGVyIG9mIHByZWZlcmVuY2Ugd2l0aCB0aGUKK21v c3QgcHJlZmVycmVkIGdyb3VwIGZpcnN0LiBUaGUgZmlyc3QgbGlzdGVkIGdyb3VwIHdpbGwg YmUgdGhlIG9uZSB1c2VkIGZvciBhCitrZXlfc2hhcmUgYnkgYSBUTFN2MS4zIGNsaWVudC4K KworPWl0ZW0gQjwtY3VydmVzPgorCitUaGlzIGlzIGEgc3lub255bSBmb3IgdGhlICItZ3Jv dXBzIiBjb21tYW5kLgorCisKID1pdGVtIEI8LW5hbWVkX2N1cnZlPgogCiBUaGlzIHNldHMg dGhlIHRlbXBvcmFyeSBjdXJ2ZSB1c2VkIGZvciBlcGhlbWVyYWwgRUNESCBtb2Rlcy4gT25s eSB1c2VkIGJ5CkBAIC0yNzMsMTYgKzI5MywyNCBAQCB1c2VkIHRvIGRldGVybWluZSB3aGlj aCBzaWduYXR1cmUgYWxnb3JpdGhtIHRvIHdpdGggdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZS4K IFRoZSBzeW50YXggb2YgQjx2YWx1ZT4gaXMgaWRlbnRpY2FsIHRvIEI8U2lnbmF0dXJlQWxn b3JpdGhtcz4uIElmIG5vdCBzZXQgdGhlbgogdGhlIHZhbHVlIHNldCBmb3IgQjxTaWduYXR1 cmVBbGdvcml0aG1zPiB3aWxsIGJlIHVzZWQgaW5zdGVhZC4KIAotPWl0ZW0gQjxDdXJ2ZXM+ Cis9aXRlbSBCPEdyb3Vwcz4KIAotVGhpcyBzZXRzIHRoZSBzdXBwb3J0ZWQgZWxsaXB0aWMg Y3VydmVzLiBGb3IgY2xpZW50cyB0aGUgY3VydmVzIGFyZQotc2VudCB1c2luZyB0aGUgc3Vw cG9ydGVkIGN1cnZlcyBleHRlbnNpb24uIEZvciBzZXJ2ZXJzIGl0IGlzIHVzZWQKLXRvIGRl dGVybWluZSB3aGljaCBjdXJ2ZSB0byB1c2UuIFRoaXMgc2V0dGluZyBhZmZlY3RzIGN1cnZl cyB1c2VkIGZvciBib3RoCi1zaWduYXR1cmVzIGFuZCBrZXkgZXhjaGFuZ2UsIGlmIGFwcGxp Y2FibGUuCitUaGlzIHNldHMgdGhlIHN1cHBvcnRlZCBncm91cHMuIEZvciBjbGllbnRzLCB0 aGUgZ3JvdXBzIGFyZQorc2VudCB1c2luZyB0aGUgc3VwcG9ydGVkIGdyb3VwcyBleHRlbnNp b24uIEZvciBzZXJ2ZXJzLCBpdCBpcyB1c2VkCit0byBkZXRlcm1pbmUgd2hpY2ggZ3JvdXAg dG8gdXNlLiBUaGlzIHNldHRpbmcgYWZmZWN0cyBncm91cHMgdXNlZCBmb3IgYm90aAorc2ln bmF0dXJlcyBhbmQga2V5IGV4Y2hhbmdlLCBpZiBhcHBsaWNhYmxlLiBJdCBhbHNvIGFmZmVj dHMgdGhlIHByZWZlcnJlZAora2V5X3NoYXJlIHNlbnQgYnkgYSBjbGllbnQgaW4gYSBUTFN2 MS4zIGNvbXBhdGlibGUgY29ubmVjdGlvbi4KIAotVGhlIEI8dmFsdWU+IGFyZ3VtZW50IGlz IGEgY29sb24gc2VwYXJhdGVkIGxpc3Qgb2YgY3VydmVzLiBUaGUgY3VydmUgY2FuIGJlCi1l aXRoZXIgdGhlIEI8TklTVD4gbmFtZSAoZS5nLiBCPFAtMjU2Pikgb3IgYW4gT3BlblNTTCBP SUQgbmFtZSAoZS5nCi1CPHByaW1lMjU2djE+KS4gQ3VydmUgbmFtZXMgYXJlIGNhc2Ugc2Vu c2l0aXZlLgorVGhlIEI8dmFsdWU+IGFyZ3VtZW50IGlzIGEgY29sb24gc2VwYXJhdGVkIGxp c3Qgb2YgZ3JvdXBzLiBUaGUgZ3JvdXAgY2FuIGJlCitlaXRoZXIgdGhlIEI8TklTVD4gbmFt ZSAoZS5nLiBCPFAtMjU2PiksIHNvbWUgb3RoZXIgY29tbW9ubHkgdXNlZCBuYW1lIHdoZXJl CithcHBsaWNhYmxlIChlLmcuIEI8WDI1NTE5Pikgb3IgYW4gT3BlblNTTCBPSUQgbmFtZSAo ZS5nIEI8cHJpbWUyNTZ2MT4pLiBHcm91cAorbmFtZXMgYXJlIGNhc2Ugc2Vuc2l0aXZlLiBU aGUgbGlzdCBzaG91bGQgYmUgaW4gb3JkZXIgb2YgcHJlZmVyZW5jZSB3aXRoIHRoZQorbW9z dCBwcmVmZXJyZWQgZ3JvdXAgZmlyc3QuIFRoZSBmaXJzdCBsaXN0ZWQgZ3JvdXAgd2lsbCBi ZSB0aGUgb25lIHVzZWQgZm9yIGEKK2tleV9zaGFyZSBieSBhIFRMU3YxLjMgY2xpZW50Lgor Cis9aXRlbSBCPEN1cnZlcz4KKworVGhpcyBpcyBhIHN5bm9ueW0gZm9yIHRoZSAiR3JvdXBz IiBjb21tYW5kLgogCiA9aXRlbSBCPE1pblByb3RvY29sPgogCmRpZmYgLS1naXQgYS9kb2Mv bWFuMy9TU0xfQ1RYX3VzZV9zZXJ2ZXJpbmZvLnBvZCBiL2RvYy9tYW4zL1NTTF9DVFhfdXNl X3NlcnZlcmluZm8ucG9kCmluZGV4IGJkNDk2ZmYuLmQzNWExOTYgMTAwNjQ0Ci0tLSBhL2Rv Yy9tYW4zL1NTTF9DVFhfdXNlX3NlcnZlcmluZm8ucG9kCisrKyBiL2RvYy9tYW4zL1NTTF9D VFhfdXNlX3NlcnZlcmluZm8ucG9kCkBAIC0yLDEyICsyLDE5IEBACiAKID1oZWFkMSBOQU1F CiAKLVNTTF9DVFhfdXNlX3NlcnZlcmluZm8sIFNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZmls ZSAtIHVzZSBzZXJ2ZXJpbmZvIGV4dGVuc2lvbgorU1NMX0NUWF91c2Vfc2VydmVyaW5mb19l eCwKK1NTTF9DVFhfdXNlX3NlcnZlcmluZm8sCitTU0xfQ1RYX3VzZV9zZXJ2ZXJpbmZvX2Zp bGUKKy0gdXNlIHNlcnZlcmluZm8gZXh0ZW5zaW9uCiAKID1oZWFkMSBTWU5PUFNJUwogCiAg I2luY2x1ZGUgPG9wZW5zc2wvc3NsLmg+CiAKKyBpbnQgU1NMX0NUWF91c2Vfc2VydmVyaW5m b19leChTU0xfQ1RYICpjdHgsIHVuc2lnbmVkIGludCB2ZXJzaW9uLAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGNoYXIgKnNlcnZlcmluZm8sCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZV90IHNlcnZlcmluZm9fbGVuZ3Ro KTsKKwogIGludCBTU0xfQ1RYX3VzZV9zZXJ2ZXJpbmZvKFNTTF9DVFggKmN0eCwgY29uc3Qg dW5zaWduZWQgY2hhciAqc2VydmVyaW5mbywKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzaXplX3Qgc2VydmVyaW5mb19sZW5ndGgpOwogCkBAIC0xNSwyMCArMjIsNDAgQEAgU1NM X0NUWF91c2Vfc2VydmVyaW5mbywgU1NMX0NUWF91c2Vfc2VydmVyaW5mb19maWxlIC0gdXNl IHNlcnZlcmluZm8gZXh0ZW5zaW9uCiAKID1oZWFkMSBERVNDUklQVElPTgogCi1UaGVzZSBm dW5jdGlvbnMgbG9hZCAic2VydmVyaW5mbyIgVExTIFNlcnZlckhlbGxvIEV4dGVuc2lvbnMg aW50byB0aGUgU1NMX0NUWC4KLUEgInNlcnZlcmluZm8iIGV4dGVuc2lvbiBpcyByZXR1cm5l ZCBpbiByZXNwb25zZSB0byBhbiBlbXB0eSBDbGllbnRIZWxsbworVGhlc2UgZnVuY3Rpb25z IGxvYWQgInNlcnZlcmluZm8iIFRMUyBleHRlbnNpb25zIGludG8gdGhlIFNTTF9DVFguIEEK KyJzZXJ2ZXJpbmZvIiBleHRlbnNpb24gaXMgcmV0dXJuZWQgaW4gcmVzcG9uc2UgdG8gYW4g ZW1wdHkgQ2xpZW50SGVsbG8KIEV4dGVuc2lvbi4KIAotU1NMX0NUWF91c2Vfc2VydmVyaW5m bygpIGxvYWRzIG9uZSBvciBtb3JlIHNlcnZlcmluZm8gZXh0ZW5zaW9ucyBmcm9tCi1hIGJ5 dGUgYXJyYXkgaW50byBCPGN0eD4uICBUaGUgZXh0ZW5zaW9ucyBtdXN0IGJlIGNvbmNhdGVu YXRlZCBpbnRvIGEKLXNlcXVlbmNlIG9mIGJ5dGVzLiAgRWFjaCBleHRlbnNpb24gbXVzdCBj b25zaXN0IG9mIGEgMi1ieXRlIEV4dGVuc2lvbiBUeXBlLAotYSAyLWJ5dGUgbGVuZ3RoLCBh bmQgdGhlbiBsZW5ndGggYnl0ZXMgb2YgZXh0ZW5zaW9uX2RhdGEuCitTU0xfQ1RYX3VzZV9z ZXJ2ZXJpbmZvX2V4KCkgbG9hZHMgb25lIG9yIG1vcmUgc2VydmVyaW5mbyBleHRlbnNpb25z IGZyb20KK2EgYnl0ZSBhcnJheSBpbnRvIEI8Y3R4Pi4gVGhlIEI8dmVyc2lvbj4gcGFyYW1l dGVyIHNwZWNpZmllcyB0aGUgZm9ybWF0IG9mIHRoZQorYnl0ZSBhcnJheSBwcm92aWRlZCBp biBCPCpzZXJ2ZXJpbmZvPiB3aGljaCBpcyBvZiBsZW5ndGggQjxzZXJ2ZXJpbmZvX2xlbmd0 aD4uCisKK0lmIEI8dmVyc2lvbj4gaXMgQjxTU0xfU0VSVkVSSU5GT1YyPiB0aGVuIHRoZSBl eHRlbnNpb25zIGluIHRoZSBhcnJheSBtdXN0Citjb25zaXN0IG9mIGEgNC1ieXRlIGNvbnRl eHQsIGEgMi1ieXRlIEV4dGVuc2lvbiBUeXBlLCBhIDItYnl0ZSBsZW5ndGgsIGFuZCB0aGVu CitsZW5ndGggYnl0ZXMgb2YgZXh0ZW5zaW9uX2RhdGEuIFRoZSBjb250ZXh0IGFuZCB0eXBl IHZhbHVlcyBoYXZlIHRoZSBzYW1lCittZWFuaW5nIGFzIGZvciBMPFNTTF9DVFhfYWRkX2N1 c3RvbV9leHQoMyk+LiBJZiBzZXJ2ZXJpbmZvIGlzIGJlaW5nIGxvYWRlZCBmb3IKK2V4dGVu c2lvbnMgdG8gYmUgYWRkZWQgdG8gYSBDZXJ0aWZpY2F0ZSBtZXNzYWdlLCB0aGVuIHRoZSBl eHRlbnNpb24gd2lsbCBvbmx5CitiZSBhZGRlZCBmb3IgdGhlIGZpcnN0IGNlcnRpZmljYXRl IGluIHRoZSBtZXNzYWdlICh3aGljaCBpcyBhbHdheXMgdGhlCitlbmQtZW50aXR5IGNlcnRp ZmljYXRlKS4KKworSWYgQjx2ZXJzaW9uPiBpcyBCPFNTTF9TRVJWRVJJTkZPVjE+IHRoZW4g dGhlIGV4dGVuc2lvbnMgaW4gdGhlIGFycmF5IG11c3QKK2NvbnNpc3Qgb2YgYSAyLWJ5dGUg RXh0ZW5zaW9uIFR5cGUsIGEgMi1ieXRlIGxlbmd0aCwgYW5kIHRoZW4gbGVuZ3RoIGJ5dGVz IG9mCitleHRlbnNpb25fZGF0YS4gVGhlIHR5cGUgdmFsdWUgaGFzIHRoZSBzYW1lIG1lYW5p bmcgYXMgZm9yCitMPFNTTF9DVFhfYWRkX2N1c3RvbV9leHQoMyk+LiBUaGUgZm9sbG93aW5n IGRlZmF1bHQgY29udGV4dCB2YWx1ZSB3aWxsIGJlIHVzZWQKK2luIHRoaXMgY2FzZToKKwor IFNTTF9FWFRfVExTMV8yX0FORF9CRUxPV19PTkxZIHwgU1NMX0VYVF9DTElFTlRfSEVMTE8K KyB8IFNTTF9FWFRfVExTMV8yX1NFUlZFUl9IRUxMTyB8IFNTTF9FWFRfSUdOT1JFX09OX1JF U1VNUFRJT04KKworU1NMX0NUWF91c2Vfc2VydmVyaW5mbygpIGRvZXMgdGhlIHNhbWUgdGhp bmcgYXMgU1NMX0NUWF91c2Vfc2VydmVyaW5mb19leCgpCitleGNlcHQgdGhhdCB0aGVyZSBp cyBubyBCPHZlcnNpb24+IHBhcmFtZXRlciBzbyBhIGRlZmF1bHQgdmVyc2lvbiBvZgorU1NM X1NFUlZFUklORk9WMSBpcyB1c2VkIGluc3RlYWQuCiAKIFNTTF9DVFhfdXNlX3NlcnZlcmlu Zm9fZmlsZSgpIGxvYWRzIG9uZSBvciBtb3JlIHNlcnZlcmluZm8gZXh0ZW5zaW9ucyBmcm9t CiBCPGZpbGU+IGludG8gQjxjdHg+LiAgVGhlIGV4dGVuc2lvbnMgbXVzdCBiZSBpbiBQRU0g Zm9ybWF0LiAgRWFjaCBleHRlbnNpb24KLW11c3QgY29uc2lzdCBvZiBhIDItYnl0ZSBFeHRl bnNpb24gVHlwZSwgYSAyLWJ5dGUgbGVuZ3RoLCBhbmQgdGhlbiBsZW5ndGgKLWJ5dGVzIG9m IGV4dGVuc2lvbl9kYXRhLiAgRWFjaCBQRU0gZXh0ZW5zaW9uIG5hbWUgbXVzdCBiZWdpbiB3 aXRoIHRoZSBwaHJhc2UKLSJCRUdJTiBTRVJWRVJJTkZPIEZPUiAiLgorbXVzdCBiZSBpbiBh IGZvcm1hdCBhcyBkZXNjcmliZWQgYWJvdmUgZm9yIFNTTF9DVFhfdXNlX3NlcnZlcmluZm9f ZXgoKS4gIEVhY2gKK1BFTSBleHRlbnNpb24gbmFtZSBtdXN0IGJlZ2luIHdpdGggdGhlIHBo cmFzZSAiQkVHSU4gU0VSVkVSSU5GT1YyIEZPUiAiIGZvcgorU1NMX1NFUlZFUklORk9WMiBk YXRhIG9yICJCRUdJTiBTRVJWRVJJTkZPIEZPUiAiIGZvciBTU0xfU0VSVkVSSU5GT1YxIGRh dGEuCiAKIElmIG1vcmUgdGhhbiBvbmUgY2VydGlmaWNhdGUgKFJTQS9EU0EpIGlzIGluc3Rh bGxlZCB1c2luZwogU1NMX0NUWF91c2VfY2VydGlmaWNhdGUoKSwgdGhlIHNlcnZlcmluZm8g ZXh0ZW5zaW9uIHdpbGwgYmUgbG9hZGVkIGludG8gdGhlCkBAIC0zNiw3ICs2Myw3IEBAIGxh c3QgY2VydGlmaWNhdGUgaW5zdGFsbGVkLiAgSWYgZS5nLiB0aGUgbGFzdCBpdGVtIHdhcyBh IFJTQSBjZXJ0aWZpY2F0ZSwgdGhlCiBsb2FkZWQgc2VydmVyaW5mbyBleHRlbnNpb24gZGF0 YSB3aWxsIGJlIGxvYWRlZCBmb3IgdGhhdCBjZXJ0aWZpY2F0ZS4gIFRvCiB1c2UgdGhlIHNl cnZlcmluZm8gZXh0ZW5zaW9uIGZvciBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXMsCiBTU0xfQ1RY X3VzZV9zZXJ2ZXJpbmZvKCkgbmVlZHMgdG8gYmUgY2FsbGVkIG11bHRpcGxlIHRpbWVzLCBv bmNlIEI8YWZ0ZXI+Ci1lYWNoIHRpbWUgYSBjZXJ0aWZpY2F0ZSBpcyBsb2FkZWQuCitlYWNo IHRpbWUgYSBjZXJ0aWZpY2F0ZSBpcyBsb2FkZWQgdmlhIGEgY2FsbCB0byBTU0xfQ1RYX3Vz ZV9jZXJ0aWZpY2F0ZSgpLgogCiA9aGVhZDEgUkVUVVJOIFZBTFVFUwogCkBAIC00Niw3ICs3 Myw3IEBAIHRoZSByZWFzb24uCiAKID1oZWFkMSBDT1BZUklHSFQKIAotQ29weXJpZ2h0IDIw MTMtMjAxNiBUaGUgT3BlblNTTCBQcm9qZWN0IEF1dGhvcnMuIEFsbCBSaWdodHMgUmVzZXJ2 ZWQuCitDb3B5cmlnaHQgMjAxMy0yMDE3IFRoZSBPcGVuU1NMIFByb2plY3QgQXV0aG9ycy4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4KIAogTGljZW5zZWQgdW5kZXIgdGhlIE9wZW5TU0wgbGlj ZW5zZSAodGhlICJMaWNlbnNlIikuICBZb3UgbWF5IG5vdCB1c2UKIHRoaXMgZmlsZSBleGNl cHQgaW4gY29tcGxpYW5jZSB3aXRoIHRoZSBMaWNlbnNlLiAgWW91IGNhbiBvYnRhaW4gYSBj b3B5CmRpZmYgLS1naXQgYS9pbmNsdWRlL29wZW5zc2wvb2JqX21hYy5oIGIvaW5jbHVkZS9v cGVuc3NsL29ial9tYWMuaAppbmRleCBkOWM0NWRlLi4zNzYyZTUxIDEwMDY0NAotLS0gYS9p bmNsdWRlL29wZW5zc2wvb2JqX21hYy5oCisrKyBiL2luY2x1ZGUvb3BlbnNzbC9vYmpfbWFj LmgKQEAgLTkzMiw2ICs5MzIsMTAgQEAKICNkZWZpbmUgTklEX2lkX3NtaW1lX2FhX2R2Y3Nf ZHZjICAgICAgICAgICAgICAgIDI0MAogI2RlZmluZSBPQkpfaWRfc21pbWVfYWFfZHZjc19k dmMgICAgICAgICAgICAgICAgT0JKX2lkX3NtaW1lX2FhLDI5TAogCisjZGVmaW5lIFNOX2lk X3NtaW1lX2FhX3NpZ25pbmdDZXJ0aWZpY2F0ZVYyICAgICAgICAgICAgICJpZC1zbWltZS1h YS1zaWduaW5nQ2VydGlmaWNhdGVWMiIKKyNkZWZpbmUgTklEX2lkX3NtaW1lX2FhX3NpZ25p bmdDZXJ0aWZpY2F0ZVYyICAgICAgICAgICAgMTA4NgorI2RlZmluZSBPQkpfaWRfc21pbWVf YWFfc2lnbmluZ0NlcnRpZmljYXRlVjIgICAgICAgICAgICBPQkpfaWRfc21pbWVfYWEsMzBM CisKICNkZWZpbmUgU05faWRfc21pbWVfYWxnX0VTREh3aXRoM0RFUyAgICAgICAgICAgICJp ZC1zbWltZS1hbGctRVNESHdpdGgzREVTIgogI2RlZmluZSBOSURfaWRfc21pbWVfYWxnX0VT REh3aXRoM0RFUyAgICAgICAgICAgMjQxCiAjZGVmaW5lIE9CSl9pZF9zbWltZV9hbGdfRVNE SHdpdGgzREVTICAgICAgICAgICBPQkpfaWRfc21pbWVfYWxnLDFMCmRpZmYgLS1naXQgYS9p bmNsdWRlL29wZW5zc2wvc3NsLmggYi9pbmNsdWRlL29wZW5zc2wvc3NsLmgKaW5kZXggYjFk YTZjNS4uNzY0ZWNlYSAxMDA2NDQKLS0tIGEvaW5jbHVkZS9vcGVuc3NsL3NzbC5oCisrKyBi L2luY2x1ZGUvb3BlbnNzbC9zc2wuaApAQCAtMTQ1MSw5ICsxNDUxLDE3IEBAIF9fb3d1ciBp bnQgU1NMX3VzZV9Qcml2YXRlS2V5X0FTTjEoaW50IHBrLCBTU0wgKnNzbCwgY29uc3QgdW5z aWduZWQgY2hhciAqZCwKIF9fb3d1ciBpbnQgU1NMX3VzZV9jZXJ0aWZpY2F0ZShTU0wgKnNz bCwgWDUwOSAqeCk7CiBfX293dXIgaW50IFNTTF91c2VfY2VydGlmaWNhdGVfQVNOMShTU0wg KnNzbCwgY29uc3QgdW5zaWduZWQgY2hhciAqZCwgaW50IGxlbik7CiAKKworLyogc2VydmVy aW5mbyBmaWxlIGZvcm1hdCB2ZXJzaW9ucyAqLworIyBkZWZpbmUgU1NMX1NFUlZFUklORk9W MSAgIDEKKyMgZGVmaW5lIFNTTF9TRVJWRVJJTkZPVjIgICAyCisKIC8qIFNldCBzZXJ2ZXJp bmZvIGRhdGEgZm9yIHRoZSBjdXJyZW50IGFjdGl2ZSBjZXJ0LiAqLwogX19vd3VyIGludCBT U0xfQ1RYX3VzZV9zZXJ2ZXJpbmZvKFNTTF9DVFggKmN0eCwgY29uc3QgdW5zaWduZWQgY2hh ciAqc2VydmVyaW5mbywKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVfdCBzZXJ2 ZXJpbmZvX2xlbmd0aCk7CitfX293dXIgaW50IFNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZXgo U1NMX0NUWCAqY3R4LCB1bnNpZ25lZCBpbnQgdmVyc2lvbiwKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICpzZXJ2ZXJpbmZvLAor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVfdCBzZXJ2ZXJpbmZv X2xlbmd0aCk7CiBfX293dXIgaW50IFNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZmlsZShTU0xf Q1RYICpjdHgsIGNvbnN0IGNoYXIgKmZpbGUpOwogCiAjaWZuZGVmIE9QRU5TU0xfTk9fUlNB CkBAIC0yMzI4LDYgKzIzMzYsNyBAQCBpbnQgRVJSX2xvYWRfU1NMX3N0cmluZ3Modm9pZCk7 CiAjIGRlZmluZSBTU0xfRl9TU0xfQ1RYX1VTRV9SU0FQUklWQVRFS0VZX0FTTjEgICAgICAg ICAgICAgMTc4CiAjIGRlZmluZSBTU0xfRl9TU0xfQ1RYX1VTRV9SU0FQUklWQVRFS0VZX0ZJ TEUgICAgICAgICAgICAgMTc5CiAjIGRlZmluZSBTU0xfRl9TU0xfQ1RYX1VTRV9TRVJWRVJJ TkZPICAgICAgICAgICAgICAgICAgICAgMzM2CisjIGRlZmluZSBTU0xfRl9TU0xfQ1RYX1VT RV9TRVJWRVJJTkZPX0VYICAgICAgICAgICAgICAgICAgNTQzCiAjIGRlZmluZSBTU0xfRl9T U0xfQ1RYX1VTRV9TRVJWRVJJTkZPX0ZJTEUgICAgICAgICAgICAgICAgMzM3CiAjIGRlZmlu ZSBTU0xfRl9TU0xfREFORV9EVVAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDAz CiAjIGRlZmluZSBTU0xfRl9TU0xfREFORV9FTkFCTEUgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMzk1CmRpZmYgLS1naXQgYS9pbmNsdWRlL29wZW5zc2wvdGxzMS5oIGIvaW5jbHVk ZS9vcGVuc3NsL3RsczEuaAppbmRleCAwN2U3MzVjLi5hZWY2NWNkIDEwMDY0NAotLS0gYS9p bmNsdWRlL29wZW5zc2wvdGxzMS5oCisrKyBiL2luY2x1ZGUvb3BlbnNzbC90bHMxLmgKQEAg LTY4LDkgKzY4LDkgQEAgZXh0ZXJuICJDIiB7CiAjIGRlZmluZSBUTFMxXzNfVkVSU0lPTiAg ICAgICAgICAgICAgICAgIDB4MDMwNAogIyBkZWZpbmUgVExTX01BWF9WRVJTSU9OICAgICAg ICAgICAgICAgICBUTFMxXzNfVkVSU0lPTgogCi0vKiBUT0RPKFRMUzEuMykgUkVNT1ZFIE1F OiBWZXJzaW9uIGluZGljYXRvciBmb3IgZHJhZnQgLTE5ICovCi0jIGRlZmluZSBUTFMxXzNf VkVSU0lPTl9EUkFGVCAgICAgICAgICAgIDB4N2YxMwotIyBkZWZpbmUgVExTMV8zX1ZFUlNJ T05fRFJBRlRfVFhUICAgICAgICAiVExTIDEuMyAoZHJhZnQgMTkpIgorLyogVE9ETyhUTFMx LjMpIFJFTU9WRSBNRTogVmVyc2lvbiBpbmRpY2F0b3IgZm9yIGRyYWZ0IC0yMCAqLworIyBk ZWZpbmUgVExTMV8zX1ZFUlNJT05fRFJBRlQgICAgICAgICAgICAweDdmMTQKKyMgZGVmaW5l IFRMUzFfM19WRVJTSU9OX0RSQUZUX1RYVCAgICAgICAgIlRMUyAxLjMgKGRyYWZ0IDIwKSIK IAogLyogU3BlY2lhbCB2YWx1ZSBmb3IgbWV0aG9kIHN1cHBvcnRpbmcgbXVsdGlwbGUgdmVy c2lvbnMgKi8KICMgZGVmaW5lIFRMU19BTllfVkVSU0lPTiAgICAgICAgICAgICAgICAgMHgx MDAwMApkaWZmIC0tZ2l0IGEvaW5jbHVkZS9vcGVuc3NsL3RzLmggYi9pbmNsdWRlL29wZW5z c2wvdHMuaAppbmRleCBhNTY1OTgyLi5jZTgzNDEwIDEwMDY0NAotLS0gYS9pbmNsdWRlL29w ZW5zc2wvdHMuaAorKysgYi9pbmNsdWRlL29wZW5zc2wvdHMuaApAQCAtNjEsNiArNjEsMTEg QEAgdHlwZWRlZiBzdHJ1Y3QgRVNTX3NpZ25pbmdfY2VydCBFU1NfU0lHTklOR19DRVJUOwog CiBERUZJTkVfU1RBQ0tfT0YoRVNTX0NFUlRfSUQpCiAKK3R5cGVkZWYgc3RydWN0IEVTU19j ZXJ0X2lkX3YyX3N0IEVTU19DRVJUX0lEX1YyOwordHlwZWRlZiBzdHJ1Y3QgRVNTX3NpZ25p bmdfY2VydF92Ml9zdCBFU1NfU0lHTklOR19DRVJUX1YyOworCitERUZJTkVfU1RBQ0tfT0Yo RVNTX0NFUlRfSURfVjIpCisKIHR5cGVkZWYgc3RydWN0IFRTX3Jlc3Bfc3QgVFNfUkVTUDsK IAogVFNfUkVRICpUU19SRVFfbmV3KHZvaWQpOwpAQCAtMTU2LDYgKzE2MSwyMSBAQCBFU1Nf U0lHTklOR19DRVJUICpkMmlfRVNTX1NJR05JTkdfQ0VSVChFU1NfU0lHTklOR19DRVJUICoq YSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2ln bmVkIGNoYXIgKipwcCwgbG9uZyBsZW5ndGgpOwogRVNTX1NJR05JTkdfQ0VSVCAqRVNTX1NJ R05JTkdfQ0VSVF9kdXAoRVNTX1NJR05JTkdfQ0VSVCAqYSk7CiAKK0VTU19DRVJUX0lEX1Yy ICpFU1NfQ0VSVF9JRF9WMl9uZXcodm9pZCk7Cit2b2lkIEVTU19DRVJUX0lEX1YyX2ZyZWUo RVNTX0NFUlRfSURfVjIgKmEpOworaW50IGkyZF9FU1NfQ0VSVF9JRF9WMihjb25zdCBFU1Nf Q0VSVF9JRF9WMiAqYSwgdW5zaWduZWQgY2hhciAqKnBwKTsKK0VTU19DRVJUX0lEX1YyICpk MmlfRVNTX0NFUlRfSURfVjIoRVNTX0NFUlRfSURfVjIgKiphLAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICoqcHAsIGxvbmcgbGVu Z3RoKTsKK0VTU19DRVJUX0lEX1YyICpFU1NfQ0VSVF9JRF9WMl9kdXAoRVNTX0NFUlRfSURf VjIgKmEpOworCitFU1NfU0lHTklOR19DRVJUX1YyICpFU1NfU0lHTklOR19DRVJUX1YyX25l dyh2b2lkKTsKK3ZvaWQgRVNTX1NJR05JTkdfQ0VSVF9WMl9mcmVlKEVTU19TSUdOSU5HX0NF UlRfVjIgKmEpOworaW50IGkyZF9FU1NfU0lHTklOR19DRVJUX1YyKGNvbnN0IEVTU19TSUdO SU5HX0NFUlRfVjIgKmEsIHVuc2lnbmVkIGNoYXIgKipwcCk7CitFU1NfU0lHTklOR19DRVJU X1YyICpkMmlfRVNTX1NJR05JTkdfQ0VSVF9WMihFU1NfU0lHTklOR19DRVJUX1YyICoqYSwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVu c2lnbmVkIGNoYXIgKipwcCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvbmcgbGVuZ3RoKTsKK0VTU19TSUdOSU5HX0NFUlRfVjIgKkVTU19TSUdO SU5HX0NFUlRfVjJfZHVwKEVTU19TSUdOSU5HX0NFUlRfVjIgKmEpOworCiBpbnQgVFNfUkVR X3NldF92ZXJzaW9uKFRTX1JFUSAqYSwgbG9uZyB2ZXJzaW9uKTsKIGxvbmcgVFNfUkVRX2dl dF92ZXJzaW9uKGNvbnN0IFRTX1JFUSAqYSk7CiAKQEAgLTMxNiw2ICszMzYsNyBAQCBpbnQg VFNfUkVTUF9DVFhfc2V0X3NpZ25lcl9rZXkoVFNfUkVTUF9DVFggKmN0eCwgRVZQX1BLRVkg KmtleSk7CiAKIGludCBUU19SRVNQX0NUWF9zZXRfc2lnbmVyX2RpZ2VzdChUU19SRVNQX0NU WCAqY3R4LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IEVWUF9N RCAqc2lnbmVyX2RpZ2VzdCk7CitpbnQgVFNfUkVTUF9DVFhfc2V0X2Vzc19jZXJ0X2lkX2Rp Z2VzdChUU19SRVNQX0NUWCAqY3R4LCBjb25zdCBFVlBfTUQgKm1kKTsKIAogLyogVGhpcyBw YXJhbWV0ZXIgbXVzdCBiZSBzZXQuICovCiBpbnQgVFNfUkVTUF9DVFhfc2V0X2RlZl9wb2xp Y3koVFNfUkVTUF9DVFggKmN0eCwgY29uc3QgQVNOMV9PQkpFQ1QgKmRlZl9wb2xpY3kpOwpA QCAtNTI4LDYgKzU0OSw4IEBAIGludCBUU19DT05GX3NldF9vcmRlcmluZyhDT05GICpjb25m LCBjb25zdCBjaGFyICpzZWN0aW9uLCBUU19SRVNQX0NUWCAqY3R4KTsKIGludCBUU19DT05G X3NldF90c2FfbmFtZShDT05GICpjb25mLCBjb25zdCBjaGFyICpzZWN0aW9uLCBUU19SRVNQ X0NUWCAqY3R4KTsKIGludCBUU19DT05GX3NldF9lc3NfY2VydF9pZF9jaGFpbihDT05GICpj b25mLCBjb25zdCBjaGFyICpzZWN0aW9uLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRTX1JFU1BfQ1RYICpjdHgpOworaW50IFRTX0NPTkZfc2V0X2Vzc19jZXJ0X2lk X2RpZ2VzdChDT05GICpjb25mLCBjb25zdCBjaGFyICpzZWN0aW9uLAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUU19SRVNQX0NUWCAqY3R4KTsKIAogLyogLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KIC8q IEJFR0lOIEVSUk9SIENPREVTICovCkBAIC01NDQsOCArNTY3LDExIEBAIGludCBFUlJfbG9h ZF9UU19zdHJpbmdzKHZvaWQpOwogIyBkZWZpbmUgVFNfRl9ERUZfU0VSSUFMX0NCICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDExMAogIyBkZWZpbmUgVFNfRl9ERUZfVElNRV9D QiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExMQogIyBkZWZpbmUgVFNfRl9F U1NfQUREX1NJR05JTkdfQ0VSVCAgICAgICAgICAgICAgICAgICAgICAgIDExMgorIyBkZWZp bmUgVFNfRl9FU1NfQUREX1NJR05JTkdfQ0VSVF9WMiAgICAgICAgICAgICAgICAgICAgIDE0 NwogIyBkZWZpbmUgVFNfRl9FU1NfQ0VSVF9JRF9ORVdfSU5JVCAgICAgICAgICAgICAgICAg ICAgICAgIDExMworIyBkZWZpbmUgVFNfRl9FU1NfQ0VSVF9JRF9WMl9ORVdfSU5JVCAgICAg ICAgICAgICAgICAgICAgIDE1NgogIyBkZWZpbmUgVFNfRl9FU1NfU0lHTklOR19DRVJUX05F V19JTklUICAgICAgICAgICAgICAgICAgIDExNAorIyBkZWZpbmUgVFNfRl9FU1NfU0lHTklO R19DRVJUX1YyX05FV19JTklUICAgICAgICAgICAgICAgIDE1NwogIyBkZWZpbmUgVFNfRl9J TlRfVFNfUkVTUF9WRVJJRllfVE9LRU4gICAgICAgICAgICAgICAgICAgIDE0OQogIyBkZWZp bmUgVFNfRl9QS0NTN19UT19UU19UU1RfSU5GTyAgICAgICAgICAgICAgICAgICAgICAgIDE0 OAogIyBkZWZpbmUgVFNfRl9UU19BQ0NVUkFDWV9TRVRfTUlDUk9TICAgICAgICAgICAgICAg ICAgICAgIDExNQpAQCAtNjA2LDYgKzYzMiw3IEBAIGludCBFUlJfbG9hZF9UU19zdHJpbmdz KHZvaWQpOwogIyBkZWZpbmUgVFNfUl9DT1VMRF9OT1RfU0VUX1RJTUUgICAgICAgICAgICAg ICAgICAgICAgICAgIDExNQogIyBkZWZpbmUgVFNfUl9ERVRBQ0hFRF9DT05URU5UICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEzNAogIyBkZWZpbmUgVFNfUl9FU1NfQUREX1NJR05J TkdfQ0VSVF9FUlJPUiAgICAgICAgICAgICAgICAgIDExNgorIyBkZWZpbmUgVFNfUl9FU1Nf QUREX1NJR05JTkdfQ0VSVF9WMl9FUlJPUiAgICAgICAgICAgICAgIDEzOQogIyBkZWZpbmUg VFNfUl9FU1NfU0lHTklOR19DRVJUSUZJQ0FURV9FUlJPUiAgICAgICAgICAgICAgIDEwMQog IyBkZWZpbmUgVFNfUl9JTlZBTElEX05VTExfUE9JTlRFUiAgICAgICAgICAgICAgICAgICAg ICAgIDEwMgogIyBkZWZpbmUgVFNfUl9JTlZBTElEX1NJR05FUl9DRVJUSUZJQ0FURV9QVVJQ T1NFICAgICAgICAgIDExNwpkaWZmIC0tZ2l0IGEvc3NsL3JlY29yZC9yZWNfbGF5ZXJfczMu YyBiL3NzbC9yZWNvcmQvcmVjX2xheWVyX3MzLmMKaW5kZXggNDNjNGE5NC4uYmZmOTNlYiAx MDA2NDQKLS0tIGEvc3NsL3JlY29yZC9yZWNfbGF5ZXJfczMuYworKysgYi9zc2wvcmVjb3Jk L3JlY19sYXllcl9zMy5jCkBAIC04NjAsNyArODYwLDcgQEAgaW50IGRvX3NzbDNfd3JpdGUo U1NMICpzLCBpbnQgdHlwZSwgY29uc3QgdW5zaWduZWQgY2hhciAqYnVmLAogICAgICAgICB9 CiAKICAgICAgICAgaWYgKFNTTF9UUkVBVF9BU19UTFMxMyhzKSAmJiBzLT5lbmNfd3JpdGVf Y3R4ICE9IE5VTEwpIHsKLSAgICAgICAgICAgIHNpemVfdCBwYWRkaW5nID0gMDsKKyAgICAg ICAgICAgIHNpemVfdCBybGVuOwogCiAgICAgICAgICAgICBpZiAoIVdQQUNLRVRfcHV0X2J5 dGVzX3U4KHRoaXNwa3QsIHR5cGUpKSB7CiAgICAgICAgICAgICAgICAgU1NMZXJyKFNTTF9G X0RPX1NTTDNfV1JJVEUsIEVSUl9SX0lOVEVSTkFMX0VSUk9SKTsKQEAgLTg2OSwzNCArODY5 LDM3IEBAIGludCBkb19zc2wzX3dyaXRlKFNTTCAqcywgaW50IHR5cGUsIGNvbnN0IHVuc2ln bmVkIGNoYXIgKmJ1ZiwKICAgICAgICAgICAgIFNTTDNfUkVDT1JEX2FkZF9sZW5ndGgodGhp c3dyLCAxKTsKIAogICAgICAgICAgICAgLyogQWRkIFRMUzEuMyBwYWRkaW5nICovCi0gICAg ICAgICAgICBpZiAocy0+cmVjb3JkX3BhZGRpbmdfY2IgIT0gTlVMTCkgewotICAgICAgICAg ICAgICAgIHNpemVfdCBybGVuID0gU1NMM19SRUNPUkRfZ2V0X2xlbmd0aCh0aGlzd3IpOwot Ci0gICAgICAgICAgICAgICAgcGFkZGluZyA9IHMtPnJlY29yZF9wYWRkaW5nX2NiKHMsIHR5 cGUsIHJsZW4sIHMtPnJlY29yZF9wYWRkaW5nX2FyZyk7Ci0gICAgICAgICAgICAgICAgLyog ZG8gbm90IGFsbG93IHRoZSByZWNvcmQgdG8gZXhjZWVkIG1heCBwbGFpbnRleHQgbGVuZ3Ro ICovCi0gICAgICAgICAgICAgICAgaWYgKHBhZGRpbmcgPiAoU1NMM19SVF9NQVhfUExBSU5f TEVOR1RIIC0gcmxlbikpCi0gICAgICAgICAgICAgICAgICAgIHBhZGRpbmcgPSBTU0wzX1JU X01BWF9QTEFJTl9MRU5HVEggLSBybGVuOwotICAgICAgICAgICAgfSBlbHNlIGlmIChzLT5i bG9ja19wYWRkaW5nID4gMCkgewotICAgICAgICAgICAgICAgIHNpemVfdCBtYXNrID0gcy0+ YmxvY2tfcGFkZGluZyAtIDE7Ci0gICAgICAgICAgICAgICAgc2l6ZV90IHJlbWFpbmRlcjsK LQotICAgICAgICAgICAgICAgIC8qIG9wdGltaXplIGZvciBwb3dlciBvZiAyICovCi0gICAg ICAgICAgICAgICAgaWYgKChzLT5ibG9ja19wYWRkaW5nICYgbWFzaykgPT0gMCkKLSAgICAg ICAgICAgICAgICAgICAgcmVtYWluZGVyID0gU1NMM19SRUNPUkRfZ2V0X2xlbmd0aCh0aGlz d3IpICYgbWFzazsKLSAgICAgICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgICAg IHJlbWFpbmRlciA9IFNTTDNfUkVDT1JEX2dldF9sZW5ndGgodGhpc3dyKSAlIHMtPmJsb2Nr X3BhZGRpbmc7Ci0gICAgICAgICAgICAgICAgLyogZG9uJ3Qgd2FudCB0byBhZGQgYSBibG9j ayBvZiBwYWRkaW5nIGlmIHdlIGRvbid0IGhhdmUgdG8gKi8KLSAgICAgICAgICAgICAgICBp ZiAocmVtYWluZGVyID09IDApCi0gICAgICAgICAgICAgICAgICAgIHBhZGRpbmcgPSAwOwot ICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAgICAgICAgICAgcGFkZGluZyA9IHMt PmJsb2NrX3BhZGRpbmcgLSByZW1haW5kZXI7Ci0gICAgICAgICAgICB9Ci0gICAgICAgICAg ICBpZiAocGFkZGluZyA+IDApIHsKLSAgICAgICAgICAgICAgICBpZiAoIVdQQUNLRVRfbWVt c2V0KHRoaXNwa3QsIDAsIHBhZGRpbmcpKSB7Ci0gICAgICAgICAgICAgICAgICAgIFNTTGVy cihTU0xfRl9ET19TU0wzX1dSSVRFLCBFUlJfUl9JTlRFUk5BTF9FUlJPUik7Ci0gICAgICAg ICAgICAgICAgICAgIGdvdG8gZXJyOworICAgICAgICAgICAgcmxlbiA9IFNTTDNfUkVDT1JE X2dldF9sZW5ndGgodGhpc3dyKTsKKyAgICAgICAgICAgIGlmIChybGVuIDwgU1NMM19SVF9N QVhfUExBSU5fTEVOR1RIKSB7CisgICAgICAgICAgICAgICAgc2l6ZV90IHBhZGRpbmcgPSAw OworICAgICAgICAgICAgICAgIHNpemVfdCBtYXhfcGFkZGluZyA9IFNTTDNfUlRfTUFYX1BM QUlOX0xFTkdUSCAtIHJsZW47CisgICAgICAgICAgICAgICAgaWYgKHMtPnJlY29yZF9wYWRk aW5nX2NiICE9IE5VTEwpIHsKKyAgICAgICAgICAgICAgICAgICAgcGFkZGluZyA9IHMtPnJl Y29yZF9wYWRkaW5nX2NiKHMsIHR5cGUsIHJsZW4sIHMtPnJlY29yZF9wYWRkaW5nX2FyZyk7 CisgICAgICAgICAgICAgICAgfSBlbHNlIGlmIChzLT5ibG9ja19wYWRkaW5nID4gMCkgewor ICAgICAgICAgICAgICAgICAgICBzaXplX3QgbWFzayA9IHMtPmJsb2NrX3BhZGRpbmcgLSAx OworICAgICAgICAgICAgICAgICAgICBzaXplX3QgcmVtYWluZGVyOworCisgICAgICAgICAg ICAgICAgICAgIC8qIG9wdGltaXplIGZvciBwb3dlciBvZiAyICovCisgICAgICAgICAgICAg ICAgICAgIGlmICgocy0+YmxvY2tfcGFkZGluZyAmIG1hc2spID09IDApCisgICAgICAgICAg ICAgICAgICAgICAgICByZW1haW5kZXIgPSBybGVuICYgbWFzazsKKyAgICAgICAgICAgICAg ICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgcmVtYWluZGVyID0gcmxlbiAl IHMtPmJsb2NrX3BhZGRpbmc7CisgICAgICAgICAgICAgICAgICAgIC8qIGRvbid0IHdhbnQg dG8gYWRkIGEgYmxvY2sgb2YgcGFkZGluZyBpZiB3ZSBkb24ndCBoYXZlIHRvICovCisgICAg ICAgICAgICAgICAgICAgIGlmIChyZW1haW5kZXIgPT0gMCkKKyAgICAgICAgICAgICAgICAg ICAgICAgIHBhZGRpbmcgPSAwOworICAgICAgICAgICAgICAgICAgICBlbHNlCisgICAgICAg ICAgICAgICAgICAgICAgICBwYWRkaW5nID0gcy0+YmxvY2tfcGFkZGluZyAtIHJlbWFpbmRl cjsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgaWYgKHBhZGRpbmcgPiAw KSB7CisgICAgICAgICAgICAgICAgICAgIC8qIGRvIG5vdCBhbGxvdyB0aGUgcmVjb3JkIHRv IGV4Y2VlZCBtYXggcGxhaW50ZXh0IGxlbmd0aCAqLworICAgICAgICAgICAgICAgICAgICBp ZiAocGFkZGluZyA+IG1heF9wYWRkaW5nKQorICAgICAgICAgICAgICAgICAgICAgICAgcGFk ZGluZyA9IG1heF9wYWRkaW5nOworICAgICAgICAgICAgICAgICAgICBpZiAoIVdQQUNLRVRf bWVtc2V0KHRoaXNwa3QsIDAsIHBhZGRpbmcpKSB7CisgICAgICAgICAgICAgICAgICAgICAg ICBTU0xlcnIoU1NMX0ZfRE9fU1NMM19XUklURSwgRVJSX1JfSU5URVJOQUxfRVJST1IpOwor ICAgICAgICAgICAgICAgICAgICAgICAgZ290byBlcnI7CisgICAgICAgICAgICAgICAgICAg IH0KKyAgICAgICAgICAgICAgICAgICAgU1NMM19SRUNPUkRfYWRkX2xlbmd0aCh0aGlzd3Is IHBhZGRpbmcpOwogICAgICAgICAgICAgICAgIH0KLSAgICAgICAgICAgICAgICBTU0wzX1JF Q09SRF9hZGRfbGVuZ3RoKHRoaXN3ciwgcGFkZGluZyk7CiAgICAgICAgICAgICB9CiAgICAg ICAgIH0KIApkaWZmIC0tZ2l0IGEvc3NsL3NzbF9lcnIuYyBiL3NzbC9zc2xfZXJyLmMKaW5k ZXggMjk2Y2UwZC4uYTg0NWRhZSAxMDA2NDQKLS0tIGEvc3NsL3NzbF9lcnIuYworKysgYi9z c2wvc3NsX2Vyci5jCkBAIC0xNzQsNiArMTc0LDcgQEAgc3RhdGljIEVSUl9TVFJJTkdfREFU QSBTU0xfc3RyX2Z1bmN0c1tdID0gewogICAgIHtFUlJfRlVOQyhTU0xfRl9TU0xfQ1RYX1VT RV9SU0FQUklWQVRFS0VZX0ZJTEUpLAogICAgICAiU1NMX0NUWF91c2VfUlNBUHJpdmF0ZUtl eV9maWxlIn0sCiAgICAge0VSUl9GVU5DKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk8p LCAiU1NMX0NUWF91c2Vfc2VydmVyaW5mbyJ9LAorICAgIHtFUlJfRlVOQyhTU0xfRl9TU0xf Q1RYX1VTRV9TRVJWRVJJTkZPX0VYKSwgIlNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZXgifSwK ICAgICB7RVJSX0ZVTkMoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GT19GSUxFKSwKICAg ICAgIlNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZmlsZSJ9LAogICAgIHtFUlJfRlVOQyhTU0xf Rl9TU0xfREFORV9EVVApLCAic3NsX2RhbmVfZHVwIn0sCmRpZmYgLS1naXQgYS9zc2wvc3Ns X3JzYS5jIGIvc3NsL3NzbF9yc2EuYwppbmRleCA4N2JlNjQ2Li5mMGEwNThlIDEwMDY0NAot LS0gYS9zc2wvc3NsX3JzYS5jCisrKyBiL3NzbC9zc2xfcnNhLmMKQEAgLTksNiArOSw3IEBA CiAKICNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgInNzbF9sb2NsLmgiCisjaW5jbHVk ZSAicGFja2V0X2xvY2wuaCIKICNpbmNsdWRlIDxvcGVuc3NsL2Jpby5oPgogI2luY2x1ZGUg PG9wZW5zc2wvb2JqZWN0cy5oPgogI2luY2x1ZGUgPG9wZW5zc2wvZXZwLmg+CkBAIC02OTMs NTAgKzY5NCw0MyBAQCBzdGF0aWMgaW50IHNlcnZlcmluZm9fZmluZF9leHRlbnNpb24oY29u c3QgdW5zaWduZWQgY2hhciAqc2VydmVyaW5mbywKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICoqZXh0ZW5zaW9uX2RhdGEsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZV90ICpleHRlbnNpb25f bGVuZ3RoKQogeworICAgIFBBQ0tFVCBwa3QsIGRhdGE7CisKICAgICAqZXh0ZW5zaW9uX2Rh dGEgPSBOVUxMOwogICAgICpleHRlbnNpb25fbGVuZ3RoID0gMDsKICAgICBpZiAoc2VydmVy aW5mbyA9PSBOVUxMIHx8IHNlcnZlcmluZm9fbGVuZ3RoID09IDApCiAgICAgICAgIHJldHVy biAtMTsKKworICAgIGlmICghUEFDS0VUX2J1Zl9pbml0KCZwa3QsIHNlcnZlcmluZm8sIHNl cnZlcmluZm9fbGVuZ3RoKSkKKyAgICAgICAgcmV0dXJuIC0xOworCiAgICAgZm9yICg7Oykg ewogICAgICAgICB1bnNpZ25lZCBpbnQgdHlwZSA9IDA7Ci0gICAgICAgIHNpemVfdCBsZW4g PSAwOworICAgICAgICB1bnNpZ25lZCBsb25nIGNvbnRleHQgPSAwOwogCiAgICAgICAgIC8q IGVuZCBvZiBzZXJ2ZXJpbmZvICovCi0gICAgICAgIGlmIChzZXJ2ZXJpbmZvX2xlbmd0aCA9 PSAwKQorICAgICAgICBpZiAoUEFDS0VUX3JlbWFpbmluZygmcGt0KSA9PSAwKQogICAgICAg ICAgICAgcmV0dXJuIDA7ICAgICAgICAgICAvKiBFeHRlbnNpb24gbm90IGZvdW5kICovCiAK LSAgICAgICAgLyogcmVhZCAyLWJ5dGUgdHlwZSBmaWVsZCAqLwotICAgICAgICBpZiAoc2Vy dmVyaW5mb19sZW5ndGggPCAyKQotICAgICAgICAgICAgcmV0dXJuIC0xOyAgICAgICAgICAv KiBFcnJvciAqLwotICAgICAgICB0eXBlID0gKHNlcnZlcmluZm9bMF0gPDwgOCkgKyBzZXJ2 ZXJpbmZvWzFdOwotICAgICAgICBzZXJ2ZXJpbmZvICs9IDI7Ci0gICAgICAgIHNlcnZlcmlu Zm9fbGVuZ3RoIC09IDI7Ci0KLSAgICAgICAgLyogcmVhZCAyLWJ5dGUgbGVuIGZpZWxkICov Ci0gICAgICAgIGlmIChzZXJ2ZXJpbmZvX2xlbmd0aCA8IDIpCi0gICAgICAgICAgICByZXR1 cm4gLTE7ICAgICAgICAgIC8qIEVycm9yICovCi0gICAgICAgIGxlbiA9IChzZXJ2ZXJpbmZv WzBdIDw8IDgpICsgc2VydmVyaW5mb1sxXTsKLSAgICAgICAgc2VydmVyaW5mbyArPSAyOwot ICAgICAgICBzZXJ2ZXJpbmZvX2xlbmd0aCAtPSAyOwotCi0gICAgICAgIGlmIChsZW4gPiBz ZXJ2ZXJpbmZvX2xlbmd0aCkKLSAgICAgICAgICAgIHJldHVybiAtMTsgICAgICAgICAgLyog RXJyb3IgKi8KKyAgICAgICAgaWYgKCFQQUNLRVRfZ2V0X25ldF80KCZwa3QsICZjb250ZXh0 KQorICAgICAgICAgICAgICAgIHx8ICFQQUNLRVRfZ2V0X25ldF8yKCZwa3QsICZ0eXBlKQor ICAgICAgICAgICAgICAgIHx8ICFQQUNLRVRfZ2V0X2xlbmd0aF9wcmVmaXhlZF8yKCZwa3Qs ICZkYXRhKSkKKyAgICAgICAgICAgIHJldHVybiAtMTsKIAogICAgICAgICBpZiAodHlwZSA9 PSBleHRlbnNpb25fdHlwZSkgewotICAgICAgICAgICAgKmV4dGVuc2lvbl9kYXRhID0gc2Vy dmVyaW5mbzsKLSAgICAgICAgICAgICpleHRlbnNpb25fbGVuZ3RoID0gbGVuOworICAgICAg ICAgICAgKmV4dGVuc2lvbl9kYXRhID0gUEFDS0VUX2RhdGEoJmRhdGEpOworICAgICAgICAg ICAgKmV4dGVuc2lvbl9sZW5ndGggPSBQQUNLRVRfcmVtYWluaW5nKCZkYXRhKTs7CiAgICAg ICAgICAgICByZXR1cm4gMTsgICAgICAgICAgIC8qIFN1Y2Nlc3MgKi8KICAgICAgICAgfQot Ci0gICAgICAgIHNlcnZlcmluZm8gKz0gbGVuOwotICAgICAgICBzZXJ2ZXJpbmZvX2xlbmd0 aCAtPSBsZW47CiAgICAgfQogICAgIC8qIFVucmVhY2hhYmxlICovCiB9CiAKLXN0YXRpYyBp bnQgc2VydmVyaW5mb19zcnZfcGFyc2VfY2IoU1NMICpzLCB1bnNpZ25lZCBpbnQgZXh0X3R5 cGUsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2lnbmVk IGNoYXIgKmluLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3Qg aW5sZW4sIGludCAqYWwsIHZvaWQgKmFyZykKK3N0YXRpYyBpbnQgc2VydmVyaW5mb2V4X3Ny dl9wYXJzZV9jYihTU0wgKnMsIHVuc2lnbmVkIGludCBleHRfdHlwZSwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY29udGV4dCwKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICpp biwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3QgaW5sZW4s IFg1MDkgKngsIHNpemVfdCBjaGFpbmlkeCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbnQgKmFsLCB2b2lkICphcmcpCiB7CiAKICAgICBpZiAoaW5sZW4gIT0g MCkgewpAQCAtNzQ3LDEzICs3NDEsMjcgQEAgc3RhdGljIGludCBzZXJ2ZXJpbmZvX3Nydl9w YXJzZV9jYihTU0wgKnMsIHVuc2lnbmVkIGludCBleHRfdHlwZSwKICAgICByZXR1cm4gMTsK IH0KIAotc3RhdGljIGludCBzZXJ2ZXJpbmZvX3Nydl9hZGRfY2IoU1NMICpzLCB1bnNpZ25l ZCBpbnQgZXh0X3R5cGUsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCB1bnNpZ25lZCBjaGFyICoqb3V0LCBzaXplX3QgKm91dGxlbiwKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGludCAqYWwsIHZvaWQgKmFyZykKK3N0YXRpYyBpbnQgc2Vy dmVyaW5mb19zcnZfcGFyc2VfY2IoU1NMICpzLCB1bnNpZ25lZCBpbnQgZXh0X3R5cGUsCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGNoYXIg KmluLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3QgaW5sZW4s IGludCAqYWwsIHZvaWQgKmFyZykKK3sKKyAgICByZXR1cm4gc2VydmVyaW5mb2V4X3Nydl9w YXJzZV9jYihzLCBleHRfdHlwZSwgMCwgaW4sIGlubGVuLCBOVUxMLCAwLCBhbCwKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmcpOworfQorCitzdGF0aWMgaW50 IHNlcnZlcmluZm9leF9zcnZfYWRkX2NiKFNTTCAqcywgdW5zaWduZWQgaW50IGV4dF90eXBl LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY29u dGV4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgdW5zaWdu ZWQgY2hhciAqKm91dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6 ZV90ICpvdXRsZW4sIFg1MDkgKngsIHNpemVfdCBjaGFpbmlkeCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaW50ICphbCwgdm9pZCAqYXJnKQogewogICAgIGNvbnN0 IHVuc2lnbmVkIGNoYXIgKnNlcnZlcmluZm8gPSBOVUxMOwogICAgIHNpemVfdCBzZXJ2ZXJp bmZvX2xlbmd0aCA9IDA7CiAKKyAgICAvKiBXZSBvbmx5IHN1cHBvcnQgZXh0ZW5zaW9ucyBm b3IgdGhlIGZpcnN0IENlcnRpZmljYXRlICovCisgICAgaWYgKChjb250ZXh0ICYgU1NMX0VY VF9UTFMxXzNfQ0VSVElGSUNBVEUpICE9IDAgJiYgY2hhaW5pZHggPiAwKQorICAgICAgICBy ZXR1cm4gMDsKKwogICAgIC8qIElzIHRoZXJlIHNlcnZlcmluZm8gZGF0YSBmb3IgdGhlIGNo b3NlbiBzZXJ2ZXIgY2VydD8gKi8KICAgICBpZiAoKHNzbF9nZXRfc2VydmVyX2NlcnRfc2Vy dmVyaW5mbyhzLCAmc2VydmVyaW5mbywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmc2VydmVyaW5mb19sZW5ndGgpKSAhPSAwKSB7CkBAIC03NzIsODEgKzc4 MCw5MCBAQCBzdGF0aWMgaW50IHNlcnZlcmluZm9fc3J2X2FkZF9jYihTU0wgKnMsIHVuc2ln bmVkIGludCBleHRfdHlwZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICog ZXh0ZW5zaW9uICovCiB9CiAKK3N0YXRpYyBpbnQgc2VydmVyaW5mb19zcnZfYWRkX2NiKFNT TCAqcywgdW5zaWduZWQgaW50IGV4dF90eXBlLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29uc3QgdW5zaWduZWQgY2hhciAqKm91dCwgc2l6ZV90ICpvdXRsZW4sCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgKmFsLCB2b2lkICphcmcpCit7 CisgICAgcmV0dXJuIHNlcnZlcmluZm9leF9zcnZfYWRkX2NiKHMsIGV4dF90eXBlLCAwLCBv dXQsIG91dGxlbiwgTlVMTCwgMCwgYWwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFyZyk7Cit9CisKIC8qCiAgKiBXaXRoIGEgTlVMTCBjb250ZXh0LCB0aGlzIGZ1 bmN0aW9uIGp1c3QgY2hlY2tzIHRoYXQgdGhlIHNlcnZlcmluZm8gZGF0YQogICogcGFyc2Vz IGNvcnJlY3RseS4gIFdpdGggYSBub24tTlVMTCBjb250ZXh0LCBpdCByZWdpc3RlcnMgY2Fs bGJhY2tzIGZvcgogICogdGhlIGluY2x1ZGVkIGV4dGVuc2lvbnMuCiAgKi8KLXN0YXRpYyBp bnQgc2VydmVyaW5mb19wcm9jZXNzX2J1ZmZlcihjb25zdCB1bnNpZ25lZCBjaGFyICpzZXJ2 ZXJpbmZvLAorc3RhdGljIGludCBzZXJ2ZXJpbmZvX3Byb2Nlc3NfYnVmZmVyKHVuc2lnbmVk IGludCB2ZXJzaW9uLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHVuc2lnbmVkIGNoYXIgKnNlcnZlcmluZm8sCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc2l6ZV90IHNlcnZlcmluZm9fbGVuZ3RoLCBTU0xfQ1RYICpjdHgp CiB7CisgICAgUEFDS0VUIHBrdDsKKwogICAgIGlmIChzZXJ2ZXJpbmZvID09IE5VTEwgfHwg c2VydmVyaW5mb19sZW5ndGggPT0gMCkKICAgICAgICAgcmV0dXJuIDA7Ci0gICAgZm9yICg7 OykgewotICAgICAgICB1bnNpZ25lZCBpbnQgZXh0X3R5cGUgPSAwOwotICAgICAgICBzaXpl X3QgbGVuID0gMDsKIAotICAgICAgICAvKiBlbmQgb2Ygc2VydmVyaW5mbyAqLwotICAgICAg ICBpZiAoc2VydmVyaW5mb19sZW5ndGggPT0gMCkKLSAgICAgICAgICAgIHJldHVybiAxOwot Ci0gICAgICAgIC8qIHJlYWQgMi1ieXRlIHR5cGUgZmllbGQgKi8KLSAgICAgICAgaWYgKHNl cnZlcmluZm9fbGVuZ3RoIDwgMikKLSAgICAgICAgICAgIHJldHVybiAwOwotICAgICAgICAv KiBGSVhNRTogY2hlY2sgZm9yIHR5cGVzIHdlIHVuZGVyc3RhbmQgZXhwbGljaXRseT8gKi8K LQotICAgICAgICAvKiBSZWdpc3RlciBjYWxsYmFja3MgZm9yIGV4dGVuc2lvbnMgKi8KLSAg ICAgICAgZXh0X3R5cGUgPSAoc2VydmVyaW5mb1swXSA8PCA4KSArIHNlcnZlcmluZm9bMV07 Ci0gICAgICAgIGlmIChjdHggIT0gTlVMTAotICAgICAgICAgICAgICAgICYmIGN1c3RvbV9l eHRfZmluZCgmY3R4LT5jZXJ0LT5jdXN0ZXh0LCBFTkRQT0lOVF9TRVJWRVIsCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4dF90eXBlLCBOVUxMKQotICAgICAgICAg ICAgICAgICAgID09IE5VTEwKLSAgICAgICAgICAgICAgICAmJiAhU1NMX0NUWF9hZGRfc2Vy dmVyX2N1c3RvbV9leHQoY3R4LCBleHRfdHlwZSwKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VydmVyaW5mb19zcnZfYWRkX2NiLAotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxMLCBO VUxMLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzZXJ2ZXJpbmZvX3Nydl9wYXJzZV9jYiwKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCkpCi0gICAgICAgICAgICByZXR1cm4gMDsK KyAgICBpZiAodmVyc2lvbiAhPSBTU0xfU0VSVkVSSU5GT1YxICYmIHZlcnNpb24gIT0gU1NM X1NFUlZFUklORk9WMikKKyAgICAgICAgcmV0dXJuIDA7CiAKLSAgICAgICAgc2VydmVyaW5m byArPSAyOwotICAgICAgICBzZXJ2ZXJpbmZvX2xlbmd0aCAtPSAyOworICAgIGlmICghUEFD S0VUX2J1Zl9pbml0KCZwa3QsIHNlcnZlcmluZm8sIHNlcnZlcmluZm9fbGVuZ3RoKSkKKyAg ICAgICAgcmV0dXJuIDA7CiAKLSAgICAgICAgLyogcmVhZCAyLWJ5dGUgbGVuIGZpZWxkICov Ci0gICAgICAgIGlmIChzZXJ2ZXJpbmZvX2xlbmd0aCA8IDIpCi0gICAgICAgICAgICByZXR1 cm4gMDsKLSAgICAgICAgbGVuID0gKHNlcnZlcmluZm9bMF0gPDwgOCkgKyBzZXJ2ZXJpbmZv WzFdOwotICAgICAgICBzZXJ2ZXJpbmZvICs9IDI7Ci0gICAgICAgIHNlcnZlcmluZm9fbGVu Z3RoIC09IDI7CisgICAgd2hpbGUgKFBBQ0tFVF9yZW1haW5pbmcoJnBrdCkpIHsKKyAgICAg ICAgdW5zaWduZWQgbG9uZyBjb250ZXh0ID0gMDsKKyAgICAgICAgdW5zaWduZWQgaW50IGV4 dF90eXBlID0gMDsKKyAgICAgICAgUEFDS0VUIGRhdGE7CiAKLSAgICAgICAgaWYgKGxlbiA+ IHNlcnZlcmluZm9fbGVuZ3RoKQorICAgICAgICBpZiAoIVBBQ0tFVF9nZXRfbmV0XzQoJnBr dCwgJmNvbnRleHQpCisgICAgICAgICAgICAgICAgfHwgIVBBQ0tFVF9nZXRfbmV0XzIoJnBr dCwgJmV4dF90eXBlKQorICAgICAgICAgICAgICAgIHx8ICFQQUNLRVRfZ2V0X2xlbmd0aF9w cmVmaXhlZF8yKCZwa3QsICZkYXRhKSkKICAgICAgICAgICAgIHJldHVybiAwOwogCi0gICAg ICAgIHNlcnZlcmluZm8gKz0gbGVuOwotICAgICAgICBzZXJ2ZXJpbmZvX2xlbmd0aCAtPSBs ZW47CisgICAgICAgIGlmIChjdHggPT0gTlVMTCkKKyAgICAgICAgICAgIGNvbnRpbnVlOwor CisgICAgICAgIGlmICh2ZXJzaW9uID09IFNTTF9TRVJWRVJJTkZPVjEpIHsKKyAgICAgICAg ICAgIGlmICghU1NMX0NUWF9hZGRfc2VydmVyX2N1c3RvbV9leHQoY3R4LCBleHRfdHlwZSwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VydmVy aW5mb19zcnZfYWRkX2NiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOVUxMLCBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzZXJ2ZXJpbmZvX3Nydl9wYXJzZV9jYiwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCkpCisgICAgICAgICAg ICAgICAgcmV0dXJuIDA7CisgICAgICAgIH0gZWxzZSB7CisgICAgICAgICAgICBpZiAoIVNT TF9DVFhfYWRkX2N1c3RvbV9leHQoY3R4LCBleHRfdHlwZSwgY29udGV4dCwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXJ2ZXJpbmZvZXhfc3J2X2FkZF9j YiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxMLCBOVUxM LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlcmluZm9l eF9zcnZfcGFyc2VfY2IsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTlVMTCkpCisgICAgICAgICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgIH0KICAgICB9 CisKKyAgICByZXR1cm4gMTsKIH0KIAotaW50IFNTTF9DVFhfdXNlX3NlcnZlcmluZm8oU1NM X0NUWCAqY3R4LCBjb25zdCB1bnNpZ25lZCBjaGFyICpzZXJ2ZXJpbmZvLAotICAgICAgICAg ICAgICAgICAgICAgICAgICAgc2l6ZV90IHNlcnZlcmluZm9fbGVuZ3RoKQoraW50IFNTTF9D VFhfdXNlX3NlcnZlcmluZm9fZXgoU1NMX0NUWCAqY3R4LCB1bnNpZ25lZCBpbnQgdmVyc2lv biwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGNoYXIg KnNlcnZlcmluZm8sCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3Qgc2Vy dmVyaW5mb19sZW5ndGgpCiB7CiAgICAgdW5zaWduZWQgY2hhciAqbmV3X3NlcnZlcmluZm87 CiAKICAgICBpZiAoY3R4ID09IE5VTEwgfHwgc2VydmVyaW5mbyA9PSBOVUxMIHx8IHNlcnZl cmluZm9fbGVuZ3RoID09IDApIHsKLSAgICAgICAgU1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNF X1NFUlZFUklORk8sIEVSUl9SX1BBU1NFRF9OVUxMX1BBUkFNRVRFUik7CisgICAgICAgIFNT TGVycihTU0xfRl9TU0xfQ1RYX1VTRV9TRVJWRVJJTkZPX0VYLCBFUlJfUl9QQVNTRURfTlVM TF9QQVJBTUVURVIpOwogICAgICAgICByZXR1cm4gMDsKICAgICB9Ci0gICAgaWYgKCFzZXJ2 ZXJpbmZvX3Byb2Nlc3NfYnVmZmVyKHNlcnZlcmluZm8sIHNlcnZlcmluZm9fbGVuZ3RoLCBO VUxMKSkgewotICAgICAgICBTU0xlcnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GTywg U1NMX1JfSU5WQUxJRF9TRVJWRVJJTkZPX0RBVEEpOworICAgIGlmICghc2VydmVyaW5mb19w cm9jZXNzX2J1ZmZlcih2ZXJzaW9uLCBzZXJ2ZXJpbmZvLCBzZXJ2ZXJpbmZvX2xlbmd0aCwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCkpIHsKKyAgICAgICAg U1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk9fRVgsIFNTTF9SX0lOVkFMSURf U0VSVkVSSU5GT19EQVRBKTsKICAgICAgICAgcmV0dXJuIDA7CiAgICAgfQogICAgIGlmIChj dHgtPmNlcnQtPmtleSA9PSBOVUxMKSB7Ci0gICAgICAgIFNTTGVycihTU0xfRl9TU0xfQ1RY X1VTRV9TRVJWRVJJTkZPLCBFUlJfUl9JTlRFUk5BTF9FUlJPUik7CisgICAgICAgIFNTTGVy cihTU0xfRl9TU0xfQ1RYX1VTRV9TRVJWRVJJTkZPX0VYLCBFUlJfUl9JTlRFUk5BTF9FUlJP Uik7CiAgICAgICAgIHJldHVybiAwOwogICAgIH0KICAgICBuZXdfc2VydmVyaW5mbyA9IE9Q RU5TU0xfcmVhbGxvYyhjdHgtPmNlcnQtPmtleS0+c2VydmVyaW5mbywKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzZXJ2ZXJpbmZvX2xlbmd0aCk7CiAgICAgaWYg KG5ld19zZXJ2ZXJpbmZvID09IE5VTEwpIHsKLSAgICAgICAgU1NMZXJyKFNTTF9GX1NTTF9D VFhfVVNFX1NFUlZFUklORk8sIEVSUl9SX01BTExPQ19GQUlMVVJFKTsKKyAgICAgICAgU1NM ZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk9fRVgsIEVSUl9SX01BTExPQ19GQUlM VVJFKTsKICAgICAgICAgcmV0dXJuIDA7CiAgICAgfQogICAgIGN0eC0+Y2VydC0+a2V5LT5z ZXJ2ZXJpbmZvID0gbmV3X3NlcnZlcmluZm87CkBAIC04NTcsMTMgKzg3NCwyMSBAQCBpbnQg U1NMX0NUWF91c2Vfc2VydmVyaW5mbyhTU0xfQ1RYICpjdHgsIGNvbnN0IHVuc2lnbmVkIGNo YXIgKnNlcnZlcmluZm8sCiAgICAgICogTm93IHRoYXQgdGhlIHNlcnZlcmluZm8gaXMgdmFs aWRhdGVkIGFuZCBzdG9yZWQsIGdvIGFoZWFkIGFuZAogICAgICAqIHJlZ2lzdGVyIGNhbGxi YWNrcy4KICAgICAgKi8KLSAgICBpZiAoIXNlcnZlcmluZm9fcHJvY2Vzc19idWZmZXIoc2Vy dmVyaW5mbywgc2VydmVyaW5mb19sZW5ndGgsIGN0eCkpIHsKLSAgICAgICAgU1NMZXJyKFNT TF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk8sIFNTTF9SX0lOVkFMSURfU0VSVkVSSU5GT19E QVRBKTsKKyAgICBpZiAoIXNlcnZlcmluZm9fcHJvY2Vzc19idWZmZXIodmVyc2lvbiwgc2Vy dmVyaW5mbywgc2VydmVyaW5mb19sZW5ndGgsCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGN0eCkpIHsKKyAgICAgICAgU1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NF UlZFUklORk9fRVgsIFNTTF9SX0lOVkFMSURfU0VSVkVSSU5GT19EQVRBKTsKICAgICAgICAg cmV0dXJuIDA7CiAgICAgfQogICAgIHJldHVybiAxOwogfQogCitpbnQgU1NMX0NUWF91c2Vf c2VydmVyaW5mbyhTU0xfQ1RYICpjdHgsIGNvbnN0IHVuc2lnbmVkIGNoYXIgKnNlcnZlcmlu Zm8sCisgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3Qgc2VydmVyaW5mb19sZW5n dGgpCit7CisgICAgcmV0dXJuIFNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZXgoY3R4LCBTU0xf U0VSVkVSSU5GT1YxLCBzZXJ2ZXJpbmZvLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHNlcnZlcmluZm9fbGVuZ3RoKTsKK30KKwogaW50IFNTTF9DVFhfdXNlX3Nl cnZlcmluZm9fZmlsZShTU0xfQ1RYICpjdHgsIGNvbnN0IGNoYXIgKmZpbGUpCiB7CiAgICAg dW5zaWduZWQgY2hhciAqc2VydmVyaW5mbyA9IE5VTEw7CkBAIC04NzMsMTAgKzg5OCwxMiBA QCBpbnQgU1NMX0NUWF91c2Vfc2VydmVyaW5mb19maWxlKFNTTF9DVFggKmN0eCwgY29uc3Qg Y2hhciAqZmlsZSkKICAgICBsb25nIGV4dGVuc2lvbl9sZW5ndGggPSAwOwogICAgIGNoYXIg Km5hbWUgPSBOVUxMOwogICAgIGNoYXIgKmhlYWRlciA9IE5VTEw7Ci0gICAgY2hhciBuYW1l UHJlZml4W10gPSAiU0VSVkVSSU5GTyBGT1IgIjsKKyAgICBjaGFyIG5hbWVQcmVmaXgxW10g PSAiU0VSVkVSSU5GTyBGT1IgIjsKKyAgICBjaGFyIG5hbWVQcmVmaXgyW10gPSAiU0VSVkVS SU5GT1YyIEZPUiAiOwogICAgIGludCByZXQgPSAwOwogICAgIEJJTyAqYmluID0gTlVMTDsK LSAgICBzaXplX3QgbnVtX2V4dGVuc2lvbnMgPSAwOworICAgIHNpemVfdCBudW1fZXh0ZW5z aW9ucyA9IDAsIGNvbnRleHRvZmYgPSAwOworICAgIHVuc2lnbmVkIGludCB2ZXJzaW9uOwog CiAgICAgaWYgKGN0eCA9PSBOVUxMIHx8IGZpbGUgPT0gTlVMTCkgewogICAgICAgICBTU0xl cnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GT19GSUxFLCBFUlJfUl9QQVNTRURfTlVM TF9QQVJBTUVURVIpOwpAQCAtOTA3LDMyICs5MzQsNzIgQEAgaW50IFNTTF9DVFhfdXNlX3Nl cnZlcmluZm9fZmlsZShTU0xfQ1RYICpjdHgsIGNvbnN0IGNoYXIgKmZpbGUpCiAgICAgICAg ICAgICAgICAgYnJlYWs7CiAgICAgICAgIH0KICAgICAgICAgLyogQ2hlY2sgdGhhdCBQRU0g bmFtZSBzdGFydHMgd2l0aCAiQkVHSU4gU0VSVkVSSU5GTyBGT1IgIiAqLwotICAgICAgICBp ZiAoc3RybGVuKG5hbWUpIDwgc3RybGVuKG5hbWVQcmVmaXgpKSB7CisgICAgICAgIGlmIChz dHJsZW4obmFtZSkgPCBzdHJsZW4obmFtZVByZWZpeDEpKSB7CiAgICAgICAgICAgICBTU0xl cnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GT19GSUxFLCBTU0xfUl9QRU1fTkFNRV9U T09fU0hPUlQpOwogICAgICAgICAgICAgZ290byBlbmQ7CiAgICAgICAgIH0KLSAgICAgICAg aWYgKHN0cm5jbXAobmFtZSwgbmFtZVByZWZpeCwgc3RybGVuKG5hbWVQcmVmaXgpKSAhPSAw KSB7Ci0gICAgICAgICAgICBTU0xlcnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GT19G SUxFLAotICAgICAgICAgICAgICAgICAgIFNTTF9SX1BFTV9OQU1FX0JBRF9QUkVGSVgpOwot ICAgICAgICAgICAgZ290byBlbmQ7CisgICAgICAgIGlmIChzdHJuY21wKG5hbWUsIG5hbWVQ cmVmaXgxLCBzdHJsZW4obmFtZVByZWZpeDEpKSA9PSAwKSB7CisgICAgICAgICAgICB2ZXJz aW9uID0gU1NMX1NFUlZFUklORk9WMTsKKyAgICAgICAgfSBlbHNlIHsKKyAgICAgICAgICAg IGlmIChzdHJsZW4obmFtZSkgPCBzdHJsZW4obmFtZVByZWZpeDIpKSB7CisgICAgICAgICAg ICAgICAgU1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk9fRklMRSwKKyAgICAg ICAgICAgICAgICAgICAgICAgU1NMX1JfUEVNX05BTUVfVE9PX1NIT1JUKTsKKyAgICAgICAg ICAgICAgICBnb3RvIGVuZDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmIChzdHJu Y21wKG5hbWUsIG5hbWVQcmVmaXgyLCBzdHJsZW4obmFtZVByZWZpeDIpKSAhPSAwKSB7Cisg ICAgICAgICAgICAgICAgU1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk9fRklM RSwKKyAgICAgICAgICAgICAgICAgICAgICAgU1NMX1JfUEVNX05BTUVfQkFEX1BSRUZJWCk7 CisgICAgICAgICAgICAgICAgZ290byBlbmQ7CisgICAgICAgICAgICB9CisgICAgICAgICAg ICB2ZXJzaW9uID0gU1NMX1NFUlZFUklORk9WMjsKICAgICAgICAgfQogICAgICAgICAvKgog ICAgICAgICAgKiBDaGVjayB0aGF0IHRoZSBkZWNvZGVkIFBFTSBkYXRhIGlzIHBsYXVzaWJs ZSAodmFsaWQgbGVuZ3RoIGZpZWxkKQogICAgICAgICAgKi8KLSAgICAgICAgaWYgKGV4dGVu c2lvbl9sZW5ndGggPCA0Ci0gICAgICAgICAgICB8fCAoZXh0ZW5zaW9uWzJdIDw8IDgpICsg ZXh0ZW5zaW9uWzNdICE9IGV4dGVuc2lvbl9sZW5ndGggLSA0KSB7Ci0gICAgICAgICAgICBT U0xlcnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VSVkVSSU5GT19GSUxFLCBTU0xfUl9CQURfREFU QSk7Ci0gICAgICAgICAgICBnb3RvIGVuZDsKKyAgICAgICAgaWYgKHZlcnNpb24gPT0gU1NM X1NFUlZFUklORk9WMSkgeworICAgICAgICAgICAgLyogNCBieXRlIGhlYWRlcjogMiBieXRl cyB0eXBlLCAyIGJ5dGVzIGxlbiAqLworICAgICAgICAgICAgaWYgKGV4dGVuc2lvbl9sZW5n dGggPCA0CisgICAgICAgICAgICAgICAgICAgIHx8IChleHRlbnNpb25bMl0gPDwgOCkgKyBl eHRlbnNpb25bM10KKyAgICAgICAgICAgICAgICAgICAgICAgIT0gZXh0ZW5zaW9uX2xlbmd0 aCAtIDQpIHsKKyAgICAgICAgICAgICAgICBTU0xlcnIoU1NMX0ZfU1NMX0NUWF9VU0VfU0VS VkVSSU5GT19GSUxFLCBTU0xfUl9CQURfREFUQSk7CisgICAgICAgICAgICAgICAgZ290byBl bmQ7CisgICAgICAgICAgICB9CisgICAgICAgICAgICAvKgorICAgICAgICAgICAgICogRmls ZSBkb2VzIG5vdCBoYXZlIGEgY29udGV4dCB2YWx1ZSBzbyB3ZSBtdXN0IHRha2UgYWNjb3Vu dCBvZgorICAgICAgICAgICAgICogdGhpcyBsYXRlci4KKyAgICAgICAgICAgICAqLworICAg ICAgICAgICAgY29udGV4dG9mZiA9IDQ7CisgICAgICAgIH0gZWxzZSB7CisgICAgICAgICAg ICAvKiA4IGJ5dGUgaGVhZGVyOiA0IGJ5dGVzIGNvbnRleHQsIDIgYnl0ZXMgdHlwZSwgMiBi eXRlcyBsZW4gKi8KKyAgICAgICAgICAgIGlmIChleHRlbnNpb25fbGVuZ3RoIDwgOAorICAg ICAgICAgICAgICAgICAgICB8fCAoZXh0ZW5zaW9uWzZdIDw8IDgpICsgZXh0ZW5zaW9uWzdd CisgICAgICAgICAgICAgICAgICAgICAgICE9IGV4dGVuc2lvbl9sZW5ndGggLSA4KSB7Cisg ICAgICAgICAgICAgICAgU1NMZXJyKFNTTF9GX1NTTF9DVFhfVVNFX1NFUlZFUklORk9fRklM RSwgU1NMX1JfQkFEX0RBVEEpOworICAgICAgICAgICAgICAgIGdvdG8gZW5kOworICAgICAg ICAgICAgfQogICAgICAgICB9CiAgICAgICAgIC8qIEFwcGVuZCB0aGUgZGVjb2RlZCBleHRl bnNpb24gdG8gdGhlIHNlcnZlcmluZm8gYnVmZmVyICovCi0gICAgICAgIHRtcCA9IE9QRU5T U0xfcmVhbGxvYyhzZXJ2ZXJpbmZvLCBzZXJ2ZXJpbmZvX2xlbmd0aCArIGV4dGVuc2lvbl9s ZW5ndGgpOworICAgICAgICB0bXAgPSBPUEVOU1NMX3JlYWxsb2Moc2VydmVyaW5mbywgc2Vy dmVyaW5mb19sZW5ndGggKyBleHRlbnNpb25fbGVuZ3RoCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArIGNvbnRleHRvZmYpOwogICAgICAgICBpZiAodG1w ID09IE5VTEwpIHsKICAgICAgICAgICAgIFNTTGVycihTU0xfRl9TU0xfQ1RYX1VTRV9TRVJW RVJJTkZPX0ZJTEUsIEVSUl9SX01BTExPQ19GQUlMVVJFKTsKICAgICAgICAgICAgIGdvdG8g ZW5kOwogICAgICAgICB9CiAgICAgICAgIHNlcnZlcmluZm8gPSB0bXA7Ci0gICAgICAgIG1l bWNweShzZXJ2ZXJpbmZvICsgc2VydmVyaW5mb19sZW5ndGgsIGV4dGVuc2lvbiwgZXh0ZW5z aW9uX2xlbmd0aCk7Ci0gICAgICAgIHNlcnZlcmluZm9fbGVuZ3RoICs9IGV4dGVuc2lvbl9s ZW5ndGg7CisgICAgICAgIGlmIChjb250ZXh0b2ZmID4gMCkgeworICAgICAgICAgICAgdW5z aWduZWQgaW50IHN5bnRoY29udGV4dCA9IFNTTF9FWFRfQ0xJRU5UX0hFTExPCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBTU0xfRVhUX1RMUzFfMl9TRVJW RVJfSEVMTE87CisgICAgICAgICAgICB1bnNpZ25lZCBjaGFyICpzaW5mbyA9IHNlcnZlcmlu Zm8gKyBzZXJ2ZXJpbmZvX2xlbmd0aDsKKworICAgICAgICAgICAgLyogV2Uga25vdyB0aGlz IG9ubHkgdXNlcyB0aGUgbGFzdCAyIGJ5dGVzICovCisgICAgICAgICAgICBzaW5mb1swXSA9 IDA7CisgICAgICAgICAgICBzaW5mb1sxXSA9IDA7CisgICAgICAgICAgICBzaW5mb1syXSA9 IChzeW50aGNvbnRleHQgPj4gOCkgJiAweGZmOworICAgICAgICAgICAgc2luZm9bM10gPSBz eW50aGNvbnRleHQgJiAweGZmOworICAgICAgICB9CisgICAgICAgIG1lbWNweShzZXJ2ZXJp bmZvICsgc2VydmVyaW5mb19sZW5ndGggKyBjb250ZXh0b2ZmLAorICAgICAgICAgICAgICAg ZXh0ZW5zaW9uLCBleHRlbnNpb25fbGVuZ3RoKTsKKyAgICAgICAgc2VydmVyaW5mb19sZW5n dGggKz0gZXh0ZW5zaW9uX2xlbmd0aCArIGNvbnRleHRvZmY7CiAKICAgICAgICAgT1BFTlNT TF9mcmVlKG5hbWUpOwogICAgICAgICBuYW1lID0gTlVMTDsKQEAgLTk0Miw3ICsxMDA5LDgg QEAgaW50IFNTTF9DVFhfdXNlX3NlcnZlcmluZm9fZmlsZShTU0xfQ1RYICpjdHgsIGNvbnN0 IGNoYXIgKmZpbGUpCiAgICAgICAgIGV4dGVuc2lvbiA9IE5VTEw7CiAgICAgfQogCi0gICAg cmV0ID0gU1NMX0NUWF91c2Vfc2VydmVyaW5mbyhjdHgsIHNlcnZlcmluZm8sIHNlcnZlcmlu Zm9fbGVuZ3RoKTsKKyAgICByZXQgPSBTU0xfQ1RYX3VzZV9zZXJ2ZXJpbmZvX2V4KGN0eCwg dmVyc2lvbiwgc2VydmVyaW5mbywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNlcnZlcmluZm9fbGVuZ3RoKTsKICBlbmQ6CiAgICAgLyogU1NMX0NUWF91c2Vfc2Vy dmVyaW5mbyBtYWtlcyBhIGxvY2FsIGNvcHkgb2YgdGhlIHNlcnZlcmluZm8uICovCiAgICAg T1BFTlNTTF9mcmVlKG5hbWUpOwpkaWZmIC0tZ2l0IGEvc3NsL3N0YXRlbS9leHRlbnNpb25z LmMgYi9zc2wvc3RhdGVtL2V4dGVuc2lvbnMuYwppbmRleCBmODkyNjc1Li44NDdmZjEzIDEw MDY0NAotLS0gYS9zc2wvc3RhdGVtL2V4dGVuc2lvbnMuYworKysgYi9zc2wvc3RhdGVtL2V4 dGVuc2lvbnMuYwpAQCAtMTE4Nyw3ICsxMTg3LDcgQEAgaW50IHRsc19wc2tfZG9fYmluZGVy KFNTTCAqcywgY29uc3QgRVZQX01EICptZCwgY29uc3QgdW5zaWduZWQgY2hhciAqbXNnc3Rh cnQsCiAgICAgRVZQX01EX0NUWCAqbWN0eCA9IE5VTEw7CiAgICAgdW5zaWduZWQgY2hhciBo YXNoW0VWUF9NQVhfTURfU0laRV0sIGJpbmRlcmtleVtFVlBfTUFYX01EX1NJWkVdOwogICAg IHVuc2lnbmVkIGNoYXIgZmluaXNoZWRrZXlbRVZQX01BWF9NRF9TSVpFXSwgdG1wYmluZGVy W0VWUF9NQVhfTURfU0laRV07Ci0gICAgY29uc3QgY2hhciByZXN1bXB0aW9uX2xhYmVsW10g PSAicmVzdW1wdGlvbiBwc2sgYmluZGVyIGtleSI7CisgICAgY29uc3QgY2hhciByZXN1bXB0 aW9uX2xhYmVsW10gPSAicmVzIGJpbmRlciI7CiAgICAgc2l6ZV90IGJpbmRlcnNpemUsIGhh c2hzaXplID0gRVZQX01EX3NpemUobWQpOwogICAgIGludCByZXQgPSAtMTsKIApkaWZmIC0t Z2l0IGEvc3NsL3N0YXRlbS9leHRlbnNpb25zX2N1c3QuYyBiL3NzbC9zdGF0ZW0vZXh0ZW5z aW9uc19jdXN0LmMKaW5kZXggNmRlNTllMi4uMmEyMWVjNCAxMDA2NDQKLS0tIGEvc3NsL3N0 YXRlbS9leHRlbnNpb25zX2N1c3QuYworKysgYi9zc2wvc3RhdGVtL2V4dGVuc2lvbnNfY3Vz dC5jCkBAIC0xODEsMTEgKzE4MSwxMCBAQCBpbnQgY3VzdG9tX2V4dF9hZGQoU1NMICpzLCBp bnQgY29udGV4dCwgV1BBQ0tFVCAqcGt0LCBYNTA5ICp4LCBzaXplX3QgY2hhaW5pZHgsCiAK ICAgICAgICAgaWYgKChjb250ZXh0ICYgKFNTTF9FWFRfVExTMV8yX1NFUlZFUl9IRUxMTwog ICAgICAgICAgICAgICAgICAgICAgICAgfCBTU0xfRVhUX1RMUzFfM19TRVJWRVJfSEVMTE8K LSAgICAgICAgICAgICAgICAgICAgICAgIHwgU1NMX0VYVF9UTFMxXzNfRU5DUllQVEVEX0VY VEVOU0lPTlMpKSAhPSAwKSB7Ci0gICAgICAgICAgICAvKgotICAgICAgICAgICAgICogRm9y IFNlcnZlckhlbGxvL0VuY3J5cHRlZEV4dGVuc2lvbnMgb25seSBzZW5kIGV4dGVuc2lvbnMg cHJlc2VudAotICAgICAgICAgICAgICogaW4gQ2xpZW50SGVsbG8uCi0gICAgICAgICAgICAg Ki8KKyAgICAgICAgICAgICAgICAgICAgICAgIHwgU1NMX0VYVF9UTFMxXzNfRU5DUllQVEVE X0VYVEVOU0lPTlMKKyAgICAgICAgICAgICAgICAgICAgICAgIHwgU1NMX0VYVF9UTFMxXzNf Q0VSVElGSUNBVEUKKyAgICAgICAgICAgICAgICAgICAgICAgIHwgU1NMX0VYVF9UTFMxXzNf SEVMTE9fUkVUUllfUkVRVUVTVCkpICE9IDApIHsKKyAgICAgICAgICAgIC8qIE9ubHkgc2Vu ZCBleHRlbnNpb25zIHByZXNlbnQgaW4gQ2xpZW50SGVsbG8uICovCiAgICAgICAgICAgICBp ZiAoIShtZXRoLT5leHRfZmxhZ3MgJiBTU0xfRVhUX0ZMQUdfUkVDRUlWRUQpKQogICAgICAg ICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgICB9CmRpZmYgLS1naXQgYS9zc2wvdGxzMTNf ZW5jLmMgYi9zc2wvdGxzMTNfZW5jLmMKaW5kZXggOTAzMGQxYS4uMjU1YmM5NiAxMDA2NDQK LS0tIGEvc3NsL3RsczEzX2VuYy5jCisrKyBiL3NzbC90bHMxM19lbmMuYwpAQCAtMjgsNyAr MjgsNyBAQCBpbnQgdGxzMTNfaGtkZl9leHBhbmQoU1NMICpzLCBjb25zdCBFVlBfTUQgKm1k LCBjb25zdCB1bnNpZ25lZCBjaGFyICpzZWNyZXQsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHVuc2lnbmVkIGNoYXIgKmhhc2gsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVuc2lnbmVkIGNoYXIgKm91dCwgc2l6ZV90IG91dGxlbikKIHsKLSAgICBj b25zdCB1bnNpZ25lZCBjaGFyIGxhYmVsX3ByZWZpeFtdID0gIlRMUyAxLjMsICI7CisgICAg Y29uc3QgdW5zaWduZWQgY2hhciBsYWJlbF9wcmVmaXhbXSA9ICJ0bHMxMyAiOwogICAgIEVW UF9QS0VZX0NUWCAqcGN0eCA9IEVWUF9QS0VZX0NUWF9uZXdfaWQoRVZQX1BLRVlfSEtERiwg TlVMTCk7CiAgICAgaW50IHJldDsKICAgICBzaXplX3QgaGtkZmxhYmVsbGVuOwpAQCAtMTI0 LDcgKzEyNCw3IEBAIGludCB0bHMxM19nZW5lcmF0ZV9zZWNyZXQoU1NMICpzLCBjb25zdCBF VlBfTUQgKm1kLAogICAgIHNpemVfdCBtZGxlbiwgcHJldnNlY3JldGxlbjsKICAgICBpbnQg cmV0OwogICAgIEVWUF9QS0VZX0NUWCAqcGN0eCA9IEVWUF9QS0VZX0NUWF9uZXdfaWQoRVZQ X1BLRVlfSEtERiwgTlVMTCk7Ci0gICAgc3RhdGljIGNvbnN0IGNoYXIgZGVyaXZlZF9zZWNy ZXRfbGFiZWxbXSA9ICJkZXJpdmVkIHNlY3JldCI7CisgICAgc3RhdGljIGNvbnN0IGNoYXIg ZGVyaXZlZF9zZWNyZXRfbGFiZWxbXSA9ICJkZXJpdmVkIjsKICAgICB1bnNpZ25lZCBjaGFy IHByZWV4dHJhY3RzZWNbRVZQX01BWF9NRF9TSVpFXTsKIAogICAgIGlmIChwY3R4ID09IE5V TEwpCkBAIC0zNDMsMTggKzM0MywxMiBAQCBzdGF0aWMgaW50IGRlcml2ZV9zZWNyZXRfa2V5 X2FuZF9pdihTU0wgKnMsIGludCBzZW5kaW5nLCBjb25zdCBFVlBfTUQgKm1kLAogCiBpbnQg dGxzMTNfY2hhbmdlX2NpcGhlcl9zdGF0ZShTU0wgKnMsIGludCB3aGljaCkKIHsKLSAgICBz dGF0aWMgY29uc3QgdW5zaWduZWQgY2hhciBjbGllbnRfZWFybHlfdHJhZmZpY1tdID0KLSAg ICAgICAgImNsaWVudCBlYXJseSB0cmFmZmljIHNlY3JldCI7Ci0gICAgc3RhdGljIGNvbnN0 IHVuc2lnbmVkIGNoYXIgY2xpZW50X2hhbmRzaGFrZV90cmFmZmljW10gPQotICAgICAgICAi Y2xpZW50IGhhbmRzaGFrZSB0cmFmZmljIHNlY3JldCI7Ci0gICAgc3RhdGljIGNvbnN0IHVu c2lnbmVkIGNoYXIgY2xpZW50X2FwcGxpY2F0aW9uX3RyYWZmaWNbXSA9Ci0gICAgICAgICJj bGllbnQgYXBwbGljYXRpb24gdHJhZmZpYyBzZWNyZXQiOwotICAgIHN0YXRpYyBjb25zdCB1 bnNpZ25lZCBjaGFyIHNlcnZlcl9oYW5kc2hha2VfdHJhZmZpY1tdID0KLSAgICAgICAgInNl cnZlciBoYW5kc2hha2UgdHJhZmZpYyBzZWNyZXQiOwotICAgIHN0YXRpYyBjb25zdCB1bnNp Z25lZCBjaGFyIHNlcnZlcl9hcHBsaWNhdGlvbl90cmFmZmljW10gPQotICAgICAgICAic2Vy dmVyIGFwcGxpY2F0aW9uIHRyYWZmaWMgc2VjcmV0IjsKLSAgICBzdGF0aWMgY29uc3QgdW5z aWduZWQgY2hhciByZXN1bXB0aW9uX21hc3Rlcl9zZWNyZXRbXSA9Ci0gICAgICAgICJyZXN1 bXB0aW9uIG1hc3RlciBzZWNyZXQiOworICAgIHN0YXRpYyBjb25zdCB1bnNpZ25lZCBjaGFy IGNsaWVudF9lYXJseV90cmFmZmljW10gPSAiYyBlIHRyYWZmaWMiOworICAgIHN0YXRpYyBj b25zdCB1bnNpZ25lZCBjaGFyIGNsaWVudF9oYW5kc2hha2VfdHJhZmZpY1tdID0gImMgaHMg dHJhZmZpYyI7CisgICAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNoYXIgY2xpZW50X2FwcGxp Y2F0aW9uX3RyYWZmaWNbXSA9ICJjIGFwIHRyYWZmaWMiOworICAgIHN0YXRpYyBjb25zdCB1 bnNpZ25lZCBjaGFyIHNlcnZlcl9oYW5kc2hha2VfdHJhZmZpY1tdID0gInMgaHMgdHJhZmZp YyI7CisgICAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNoYXIgc2VydmVyX2FwcGxpY2F0aW9u X3RyYWZmaWNbXSA9ICJzIGFwIHRyYWZmaWMiOworICAgIHN0YXRpYyBjb25zdCB1bnNpZ25l ZCBjaGFyIHJlc3VtcHRpb25fbWFzdGVyX3NlY3JldFtdID0gInJlcyBtYXN0ZXIiOwogICAg IHVuc2lnbmVkIGNoYXIgKml2OwogICAgIHVuc2lnbmVkIGNoYXIgc2VjcmV0W0VWUF9NQVhf TURfU0laRV07CiAgICAgdW5zaWduZWQgY2hhciBoYXNodmFsW0VWUF9NQVhfTURfU0laRV07 CkBAIC01NTksOCArNTUzLDcgQEAgaW50IHRsczEzX2NoYW5nZV9jaXBoZXJfc3RhdGUoU1NM ICpzLCBpbnQgd2hpY2gpCiAKIGludCB0bHMxM191cGRhdGVfa2V5KFNTTCAqcywgaW50IHNl bmRpbmcpCiB7Ci0gICAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNoYXIgYXBwbGljYXRpb25f dHJhZmZpY1tdID0KLSAgICAgICAgImFwcGxpY2F0aW9uIHRyYWZmaWMgc2VjcmV0IjsKKyAg ICBzdGF0aWMgY29uc3QgdW5zaWduZWQgY2hhciBhcHBsaWNhdGlvbl90cmFmZmljW10gPSAi dHJhZmZpYyB1cGQiOwogICAgIGNvbnN0IEVWUF9NRCAqbWQgPSBzc2xfaGFuZHNoYWtlX21k KHMpOwogICAgIHNpemVfdCBoYXNobGVuID0gRVZQX01EX3NpemUobWQpOwogICAgIHVuc2ln bmVkIGNoYXIgKmluc2VjcmV0LCAqaXY7CmRpZmYgLS1naXQgYS90ZXN0L0NBdHNhLmNuZiBi L3Rlc3QvQ0F0c2EuY25mCmluZGV4IGFiMmY4NGEuLmQxNjQyODcgMTAwNjQ0Ci0tLSBhL3Rl c3QvQ0F0c2EuY25mCisrKyBiL3Rlc3QvQ0F0c2EuY25mCkBAIC0xNDQsNiArMTQ0LDggQEAg dHNhX25hbWUJCT0geWVzCSMgTXVzdCB0aGUgVFNBIG5hbWUgYmUgaW5jbHVkZWQgaW4gdGhl IHJlcGx5PwogCQkJCSMgKG9wdGlvbmFsLCBkZWZhdWx0OiBubykKIGVzc19jZXJ0X2lkX2No YWluCT0geWVzCSMgTXVzdCB0aGUgRVNTIGNlcnQgaWQgY2hhaW4gYmUgaW5jbHVkZWQ/CiAJ CQkJIyAob3B0aW9uYWwsIGRlZmF1bHQ6IG5vKQorZXNzX2NlcnRfaWRfYWxnCQk9IHNoYTI1 NgkjIGFsZ29yaXRobSB0byBjb21wdXRlIGNlcnRpZmljYXRlCisJCQkJCSMgaWRlbnRpZmll ciAob3B0aW9uYWwsIGRlZmF1bHQ6IHNoYTEpCiAKIFsgdHNhX2NvbmZpZzIgXQogCmRpZmYg LS1naXQgYS90ZXN0L2J1aWxkLmluZm8gYi90ZXN0L2J1aWxkLmluZm8KaW5kZXggZDg2YWNk MS4uYjUzM2RiMyAxMDA2NDQKLS0tIGEvdGVzdC9idWlsZC5pbmZvCisrKyBiL3Rlc3QvYnVp bGQuaW5mbwpAQCAtMTcxLDcgKzE3MSw3IEBAIElOQ0xVREVfTUFJTl9fX3Rlc3RfbGlidGVz dHV0aWxfT0xCID0gL0lOQ0xVREU9TUFJTgogCiAgIFNPVVJDRVtpZ2V0ZXN0XT1pZ2V0ZXN0 LmMKICAgSU5DTFVERVtpZ2V0ZXN0XT0uLiAuLi9pbmNsdWRlCi0gIERFUEVORFtpZ2V0ZXN0 XT0uLi9saWJjcnlwdG8KKyAgREVQRU5EW2lnZXRlc3RdPS4uL2xpYmNyeXB0byBsaWJ0ZXN0 dXRpbC5hCiAKICAgU09VUkNFW3YzbmFtZXRlc3RdPXYzbmFtZXRlc3QuYwogICBJTkNMVURF W3YzbmFtZXRlc3RdPS4uIC4uL2luY2x1ZGUKZGlmZiAtLWdpdCBhL3Rlc3QvaWdldGVzdC5j IGIvdGVzdC9pZ2V0ZXN0LmMKaW5kZXggMTI0NTg2MC4uZmM4MDI3NSAxMDA2NDQKLS0tIGEv dGVzdC9pZ2V0ZXN0LmMKKysrIGIvdGVzdC9pZ2V0ZXN0LmMKQEAgLTEyLDEyICsxMiwyMSBA QAogI2luY2x1ZGUgPG9wZW5zc2wvcmFuZC5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5j bHVkZSA8c3RyaW5nLmg+Ci0jaW5jbHVkZSA8YXNzZXJ0Lmg+CiAjaW5jbHVkZSAiZV9vcy5o IgorI2luY2x1ZGUgInRlc3R1dGlsLmgiCiAKICNkZWZpbmUgVEVTVF9TSVpFICAgICAgIDEy OAogI2RlZmluZSBCSUdfVEVTVF9TSVpFIDEwMjQwCiAKKyNpZiBCSUdfVEVTVF9TSVpFIDwg VEVTVF9TSVpFCisjZXJyb3IgQklHX1RFU1RfU0laRSBpcyBzbWFsbGVyIHRoYW4gVEVTVF9T SVpFCisjZW5kaWYKKworc3RhdGljIHVuc2lnbmVkIGNoYXIgcmtleVsxNl07CitzdGF0aWMg dW5zaWduZWQgY2hhciBya2V5MlsxNl07CitzdGF0aWMgdW5zaWduZWQgY2hhciBwbGFpbnRl eHRbQklHX1RFU1RfU0laRV07CitzdGF0aWMgdW5zaWduZWQgY2hhciBzYXZlZF9pdltBRVNf QkxPQ0tfU0laRSAqIDRdOworCiBzdGF0aWMgdm9pZCBoZXhkdW1wKEZJTEUgKmYsIGNvbnN0 IGNoYXIgKnRpdGxlLCBjb25zdCB1bnNpZ25lZCBjaGFyICpzLCBpbnQgbCkKIHsKICAgICBp bnQgbiA9IDA7CkBAIC0xNDUsMTE0ICsxNTQsODggQEAgc3RhdGljIHN0cnVjdCBiaV9pZ2Vf dGVzdCBjb25zdCBiaV9pZ2VfdGVzdF92ZWN0b3JzW10gPSB7CiAKIH07CiAKLXN0YXRpYyBp bnQgcnVuX3Rlc3RfdmVjdG9ycyh2b2lkKQorc3RhdGljIGludCB0ZXN0X2lnZV92ZWN0b3Jz KGludCBuKQogewotICAgIHVuc2lnbmVkIGludCBuOwotICAgIGludCBlcnJzID0gMDsKLQot ICAgIGZvciAobiA9IDA7IG4gPCBPU1NMX05FTEVNKGlnZV90ZXN0X3ZlY3RvcnMpOyArK24p IHsKLSAgICAgICAgY29uc3Qgc3RydWN0IGlnZV90ZXN0ICpjb25zdCB2ID0gJmlnZV90ZXN0 X3ZlY3RvcnNbbl07Ci0gICAgICAgIEFFU19LRVkga2V5OwotICAgICAgICB1bnNpZ25lZCBj aGFyIGJ1ZltNQVhfVkVDVE9SX1NJWkVdOwotICAgICAgICB1bnNpZ25lZCBjaGFyIGl2W0FF U19CTE9DS19TSVpFICogMl07Ci0KLSAgICAgICAgYXNzZXJ0KHYtPmxlbmd0aCA8PSBNQVhf VkVDVE9SX1NJWkUpOwotCi0gICAgICAgIGlmICh2LT5lbmNyeXB0ID09IEFFU19FTkNSWVBU KQotICAgICAgICAgICAgQUVTX3NldF9lbmNyeXB0X2tleSh2LT5rZXksIDggKiBzaXplb2Yg di0+a2V5LCAma2V5KTsKLSAgICAgICAgZWxzZQotICAgICAgICAgICAgQUVTX3NldF9kZWNy eXB0X2tleSh2LT5rZXksIDggKiBzaXplb2Ygdi0+a2V5LCAma2V5KTsKLSAgICAgICAgbWVt Y3B5KGl2LCB2LT5pdiwgc2l6ZW9mIGl2KTsKLSAgICAgICAgQUVTX2lnZV9lbmNyeXB0KHYt PmluLCBidWYsIHYtPmxlbmd0aCwgJmtleSwgaXYsIHYtPmVuY3J5cHQpOwotCi0gICAgICAg IGlmIChtZW1jbXAodi0+b3V0LCBidWYsIHYtPmxlbmd0aCkpIHsKLSAgICAgICAgICAgIHBy aW50ZigiSUdFIHRlc3QgdmVjdG9yICVkIGZhaWxlZFxuIiwgbik7Ci0gICAgICAgICAgICBo ZXhkdW1wKHN0ZG91dCwgImtleSIsIHYtPmtleSwgc2l6ZW9mIHYtPmtleSk7Ci0gICAgICAg ICAgICBoZXhkdW1wKHN0ZG91dCwgIml2Iiwgdi0+aXYsIHNpemVvZiB2LT5pdik7Ci0gICAg ICAgICAgICBoZXhkdW1wKHN0ZG91dCwgImluIiwgdi0+aW4sIHYtPmxlbmd0aCk7Ci0gICAg ICAgICAgICBoZXhkdW1wKHN0ZG91dCwgImV4cGVjdGVkIiwgdi0+b3V0LCB2LT5sZW5ndGgp OwotICAgICAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJnb3QiLCBidWYsIHYtPmxlbmd0aCk7 Ci0KLSAgICAgICAgICAgICsrZXJyczsKLSAgICAgICAgfQotCi0gICAgICAgIC8qIHRyeSB3 aXRoIGluID09IG91dCAqLwotICAgICAgICBtZW1jcHkoaXYsIHYtPml2LCBzaXplb2YgaXYp OwotICAgICAgICBtZW1jcHkoYnVmLCB2LT5pbiwgdi0+bGVuZ3RoKTsKLSAgICAgICAgQUVT X2lnZV9lbmNyeXB0KGJ1ZiwgYnVmLCB2LT5sZW5ndGgsICZrZXksIGl2LCB2LT5lbmNyeXB0 KTsKLQotICAgICAgICBpZiAobWVtY21wKHYtPm91dCwgYnVmLCB2LT5sZW5ndGgpKSB7Ci0g ICAgICAgICAgICBwcmludGYoIklHRSB0ZXN0IHZlY3RvciAlZCBmYWlsZWQgKHdpdGggaW4g PT0gb3V0KVxuIiwgbik7Ci0gICAgICAgICAgICBoZXhkdW1wKHN0ZG91dCwgImtleSIsIHYt PmtleSwgc2l6ZW9mIHYtPmtleSk7Ci0gICAgICAgICAgICBoZXhkdW1wKHN0ZG91dCwgIml2 Iiwgdi0+aXYsIHNpemVvZiB2LT5pdik7Ci0gICAgICAgICAgICBoZXhkdW1wKHN0ZG91dCwg ImluIiwgdi0+aW4sIHYtPmxlbmd0aCk7Ci0gICAgICAgICAgICBoZXhkdW1wKHN0ZG91dCwg ImV4cGVjdGVkIiwgdi0+b3V0LCB2LT5sZW5ndGgpOwotICAgICAgICAgICAgaGV4ZHVtcChz dGRvdXQsICJnb3QiLCBidWYsIHYtPmxlbmd0aCk7Ci0KLSAgICAgICAgICAgICsrZXJyczsK LSAgICAgICAgfQorICAgIGNvbnN0IHN0cnVjdCBpZ2VfdGVzdCAqY29uc3QgdiA9ICZpZ2Vf dGVzdF92ZWN0b3JzW25dOworICAgIEFFU19LRVkga2V5OworICAgIHVuc2lnbmVkIGNoYXIg YnVmW01BWF9WRUNUT1JfU0laRV07CisgICAgdW5zaWduZWQgY2hhciBpdltBRVNfQkxPQ0tf U0laRSAqIDJdOworICAgIGludCB0ZXN0cmVzdWx0ID0gMTsKKworICAgIGlmICghVEVTVF9p bnRfbGUodi0+bGVuZ3RoLCBNQVhfVkVDVE9SX1NJWkUpKQorICAgICAgICByZXR1cm4gMDsK KworICAgIGlmICh2LT5lbmNyeXB0ID09IEFFU19FTkNSWVBUKQorICAgICAgICBBRVNfc2V0 X2VuY3J5cHRfa2V5KHYtPmtleSwgOCAqIHNpemVvZiB2LT5rZXksICZrZXkpOworICAgIGVs c2UKKyAgICAgICAgQUVTX3NldF9kZWNyeXB0X2tleSh2LT5rZXksIDggKiBzaXplb2Ygdi0+ a2V5LCAma2V5KTsKKyAgICBtZW1jcHkoaXYsIHYtPml2LCBzaXplb2YgaXYpOworICAgIEFF U19pZ2VfZW5jcnlwdCh2LT5pbiwgYnVmLCB2LT5sZW5ndGgsICZrZXksIGl2LCB2LT5lbmNy eXB0KTsKKworICAgIGlmICghVEVTVF9tZW1fZXEodi0+b3V0LCB2LT5sZW5ndGgsIGJ1Ziwg di0+bGVuZ3RoKSkgeworICAgICAgICBURVNUX2luZm8oIklHRSB0ZXN0IHZlY3RvciAlZCBm YWlsZWQiLCBuKTsKKyAgICAgICAgaGV4ZHVtcChzdGRlcnIsICJrZXkiLCB2LT5rZXksIHNp emVvZiB2LT5rZXkpOworICAgICAgICBoZXhkdW1wKHN0ZGVyciwgIml2Iiwgdi0+aXYsIHNp emVvZiB2LT5pdik7CisgICAgICAgIGhleGR1bXAoc3RkZXJyLCAiaW4iLCB2LT5pbiwgdi0+ bGVuZ3RoKTsKKyAgICAgICAgdGVzdHJlc3VsdCA9IDA7CiAgICAgfQogCi0gICAgZm9yIChu ID0gMDsgbiA8IE9TU0xfTkVMRU0oYmlfaWdlX3Rlc3RfdmVjdG9ycyk7ICsrbikgewotICAg ICAgICBjb25zdCBzdHJ1Y3QgYmlfaWdlX3Rlc3QgKmNvbnN0IHYgPSAmYmlfaWdlX3Rlc3Rf dmVjdG9yc1tuXTsKLSAgICAgICAgQUVTX0tFWSBrZXkxOwotICAgICAgICBBRVNfS0VZIGtl eTI7Ci0gICAgICAgIHVuc2lnbmVkIGNoYXIgYnVmW01BWF9WRUNUT1JfU0laRV07Ci0KLSAg ICAgICAgYXNzZXJ0KHYtPmxlbmd0aCA8PSBNQVhfVkVDVE9SX1NJWkUpOwotCi0gICAgICAg IGlmICh2LT5lbmNyeXB0ID09IEFFU19FTkNSWVBUKSB7Ci0gICAgICAgICAgICBBRVNfc2V0 X2VuY3J5cHRfa2V5KHYtPmtleTEsIDggKiB2LT5rZXlzaXplLCAma2V5MSk7Ci0gICAgICAg ICAgICBBRVNfc2V0X2VuY3J5cHRfa2V5KHYtPmtleTIsIDggKiB2LT5rZXlzaXplLCAma2V5 Mik7Ci0gICAgICAgIH0gZWxzZSB7Ci0gICAgICAgICAgICBBRVNfc2V0X2RlY3J5cHRfa2V5 KHYtPmtleTEsIDggKiB2LT5rZXlzaXplLCAma2V5MSk7Ci0gICAgICAgICAgICBBRVNfc2V0 X2RlY3J5cHRfa2V5KHYtPmtleTIsIDggKiB2LT5rZXlzaXplLCAma2V5Mik7Ci0gICAgICAg IH0KLQotICAgICAgICBBRVNfYmlfaWdlX2VuY3J5cHQodi0+aW4sIGJ1Ziwgdi0+bGVuZ3Ro LCAma2V5MSwgJmtleTIsIHYtPml2LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgdi0+ ZW5jcnlwdCk7Ci0KLSAgICAgICAgaWYgKG1lbWNtcCh2LT5vdXQsIGJ1Ziwgdi0+bGVuZ3Ro KSkgewotICAgICAgICAgICAgcHJpbnRmKCJCaWRpcmVjdGlvbmFsIElHRSB0ZXN0IHZlY3Rv ciAlZCBmYWlsZWRcbiIsIG4pOwotICAgICAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJrZXkg MSIsIHYtPmtleTEsIHNpemVvZiB2LT5rZXkxKTsKLSAgICAgICAgICAgIGhleGR1bXAoc3Rk b3V0LCAia2V5IDIiLCB2LT5rZXkyLCBzaXplb2Ygdi0+a2V5Mik7Ci0gICAgICAgICAgICBo ZXhkdW1wKHN0ZG91dCwgIml2Iiwgdi0+aXYsIHNpemVvZiB2LT5pdik7Ci0gICAgICAgICAg ICBoZXhkdW1wKHN0ZG91dCwgImluIiwgdi0+aW4sIHYtPmxlbmd0aCk7Ci0gICAgICAgICAg ICBoZXhkdW1wKHN0ZG91dCwgImV4cGVjdGVkIiwgdi0+b3V0LCB2LT5sZW5ndGgpOwotICAg ICAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJnb3QiLCBidWYsIHYtPmxlbmd0aCk7Ci0KLSAg ICAgICAgICAgICsrZXJyczsKLSAgICAgICAgfQorICAgIC8qIHRyeSB3aXRoIGluID09IG91 dCAqLworICAgIG1lbWNweShpdiwgdi0+aXYsIHNpemVvZiBpdik7CisgICAgbWVtY3B5KGJ1 Ziwgdi0+aW4sIHYtPmxlbmd0aCk7CisgICAgQUVTX2lnZV9lbmNyeXB0KGJ1ZiwgYnVmLCB2 LT5sZW5ndGgsICZrZXksIGl2LCB2LT5lbmNyeXB0KTsKKworICAgIGlmICghVEVTVF9tZW1f ZXEodi0+b3V0LCB2LT5sZW5ndGgsIGJ1Ziwgdi0+bGVuZ3RoKSkgeworICAgICAgICBURVNU X2luZm8oIklHRSB0ZXN0IHZlY3RvciAlZCBmYWlsZWQgKHdpdGggaW4gPT0gb3V0KSIsIG4p OworICAgICAgICBoZXhkdW1wKHN0ZGVyciwgImtleSIsIHYtPmtleSwgc2l6ZW9mIHYtPmtl eSk7CisgICAgICAgIGhleGR1bXAoc3RkZXJyLCAiaXYiLCB2LT5pdiwgc2l6ZW9mIHYtPml2 KTsKKyAgICAgICAgaGV4ZHVtcChzdGRlcnIsICJpbiIsIHYtPmluLCB2LT5sZW5ndGgpOwor ICAgICAgICB0ZXN0cmVzdWx0ID0gMDsKICAgICB9CiAKLSAgICByZXR1cm4gZXJyczsKKyAg ICByZXR1cm4gdGVzdHJlc3VsdDsKIH0KIAotaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiph cmd2KQorc3RhdGljIGludCB0ZXN0X2JpX2lnZV92ZWN0b3JzKGludCBuKQogewotICAgIHVu c2lnbmVkIGNoYXIgcmtleVsxNl07Ci0gICAgdW5zaWduZWQgY2hhciBya2V5MlsxNl07Ci0g ICAgQUVTX0tFWSBrZXk7CisgICAgY29uc3Qgc3RydWN0IGJpX2lnZV90ZXN0ICpjb25zdCB2 ID0gJmJpX2lnZV90ZXN0X3ZlY3RvcnNbbl07CisgICAgQUVTX0tFWSBrZXkxOwogICAgIEFF U19LRVkga2V5MjsKLSAgICB1bnNpZ25lZCBjaGFyIHBsYWludGV4dFtCSUdfVEVTVF9TSVpF XTsKLSAgICB1bnNpZ25lZCBjaGFyIGNpcGhlcnRleHRbQklHX1RFU1RfU0laRV07Ci0gICAg dW5zaWduZWQgY2hhciBjaGVja3RleHRbQklHX1RFU1RfU0laRV07Ci0gICAgdW5zaWduZWQg Y2hhciBpdltBRVNfQkxPQ0tfU0laRSAqIDRdOwotICAgIHVuc2lnbmVkIGNoYXIgc2F2ZWRf aXZbQUVTX0JMT0NLX1NJWkUgKiA0XTsKLSAgICBpbnQgZXJyID0gMDsKLSAgICB1bnNpZ25l ZCBpbnQgbjsKLSAgICB1bnNpZ25lZCBtYXRjaGVzOworICAgIHVuc2lnbmVkIGNoYXIgYnVm W01BWF9WRUNUT1JfU0laRV07CiAKLSAgICBhc3NlcnQoQklHX1RFU1RfU0laRSA+PSBURVNU X1NJWkUpOworICAgICAgICBpZiAoIVRFU1RfaW50X2xlKHYtPmxlbmd0aCwgTUFYX1ZFQ1RP Ul9TSVpFKSkKKyAgICAgICAgICAgIHJldHVybiAwOwogCi0gICAgUkFORF9ieXRlcyhya2V5 LCBzaXplb2YgcmtleSk7Ci0gICAgUkFORF9ieXRlcyhwbGFpbnRleHQsIHNpemVvZiBwbGFp bnRleHQpOwotICAgIFJBTkRfYnl0ZXMoaXYsIHNpemVvZiBpdik7Ci0gICAgbWVtY3B5KHNh dmVkX2l2LCBpdiwgc2l6ZW9mIHNhdmVkX2l2KTsKKyAgICBpZiAodi0+ZW5jcnlwdCA9PSBB RVNfRU5DUllQVCkgeworICAgICAgICBBRVNfc2V0X2VuY3J5cHRfa2V5KHYtPmtleTEsIDgg KiB2LT5rZXlzaXplLCAma2V5MSk7CisgICAgICAgIEFFU19zZXRfZW5jcnlwdF9rZXkodi0+ a2V5MiwgOCAqIHYtPmtleXNpemUsICZrZXkyKTsKKyAgICB9IGVsc2UgeworICAgICAgICBB RVNfc2V0X2RlY3J5cHRfa2V5KHYtPmtleTEsIDggKiB2LT5rZXlzaXplLCAma2V5MSk7Cisg ICAgICAgIEFFU19zZXRfZGVjcnlwdF9rZXkodi0+a2V5MiwgOCAqIHYtPmtleXNpemUsICZr ZXkyKTsKKyAgICB9CiAKLSAgICAvKiBGb3J3YXJkIElHRSBvbmx5Li4uICovCisgICAgQUVT X2JpX2lnZV9lbmNyeXB0KHYtPmluLCBidWYsIHYtPmxlbmd0aCwgJmtleTEsICZrZXkyLCB2 LT5pdiwKKyAgICAgICAgICAgICAgICAgICAgICAgdi0+ZW5jcnlwdCk7CiAKLSAgICAvKiBT dHJhaWdodCBlbmNyeXB0L2RlY3J5cHQgKi8KKyAgICBpZiAoIVRFU1RfbWVtX2VxKHYtPm91 dCwgdi0+bGVuZ3RoLCBidWYsIHYtPmxlbmd0aCkpIHsKKyAgICAgICAgaGV4ZHVtcChzdGRl cnIsICJrZXkgMSIsIHYtPmtleTEsIHNpemVvZiB2LT5rZXkxKTsKKyAgICAgICAgaGV4ZHVt cChzdGRlcnIsICJrZXkgMiIsIHYtPmtleTIsIHNpemVvZiB2LT5rZXkyKTsKKyAgICAgICAg aGV4ZHVtcChzdGRlcnIsICJpdiIsIHYtPml2LCBzaXplb2Ygdi0+aXYpOworICAgICAgICBo ZXhkdW1wKHN0ZGVyciwgImluIiwgdi0+aW4sIHYtPmxlbmd0aCk7CisgICAgICAgIHJldHVy biAwOworICAgIH0KKworICAgIHJldHVybiAxOworfQorCitzdGF0aWMgaW50IHRlc3RfaWdl X2VuY19kZWModm9pZCkKK3sKKyAgICBBRVNfS0VZIGtleTsKKyAgICB1bnNpZ25lZCBjaGFy IGl2W0FFU19CTE9DS19TSVpFICogNF07CisgICAgdW5zaWduZWQgY2hhciBjaXBoZXJ0ZXh0 W0JJR19URVNUX1NJWkVdOworICAgIHVuc2lnbmVkIGNoYXIgY2hlY2t0ZXh0W0JJR19URVNU X1NJWkVdOworCisgICAgbWVtY3B5KGl2LCBzYXZlZF9pdiwgc2l6ZW9mIGl2KTsKICAgICBB RVNfc2V0X2VuY3J5cHRfa2V5KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtleSk7CiAgICAg QUVTX2lnZV9lbmNyeXB0KHBsYWludGV4dCwgY2lwaGVydGV4dCwgVEVTVF9TSVpFLCAma2V5 LCBpdiwgQUVTX0VOQ1JZUFQpOwogCkBAIC0yNjAsMTQgKzI0MywxNiBAQCBpbnQgbWFpbihp bnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgbWVtY3B5KGl2LCBzYXZlZF9pdiwgc2l6ZW9m IGl2KTsKICAgICBBRVNfaWdlX2VuY3J5cHQoY2lwaGVydGV4dCwgY2hlY2t0ZXh0LCBURVNU X1NJWkUsICZrZXksIGl2LCBBRVNfREVDUllQVCk7CiAKLSAgICBpZiAobWVtY21wKGNoZWNr dGV4dCwgcGxhaW50ZXh0LCBURVNUX1NJWkUpKSB7Ci0gICAgICAgIHByaW50ZigiRW5jcnlw dCtkZWNyeXB0IGRvZXNuJ3QgbWF0Y2hcbiIpOwotICAgICAgICBoZXhkdW1wKHN0ZG91dCwg IlBsYWludGV4dCIsIHBsYWludGV4dCwgVEVTVF9TSVpFKTsKLSAgICAgICAgaGV4ZHVtcChz dGRvdXQsICJDaGVja3RleHQiLCBjaGVja3RleHQsIFRFU1RfU0laRSk7Ci0gICAgICAgICsr ZXJyOwotICAgIH0KKyAgICByZXR1cm4gVEVTVF9tZW1fZXEoY2hlY2t0ZXh0LCBURVNUX1NJ WkUsIHBsYWludGV4dCwgVEVTVF9TSVpFKTsKK30KKworc3RhdGljIGludCB0ZXN0X2lnZV9l bmNfY2hhaW5pbmcodm9pZCkKK3sKKyAgICBBRVNfS0VZIGtleTsKKyAgICB1bnNpZ25lZCBj aGFyIGl2W0FFU19CTE9DS19TSVpFICogNF07CisgICAgdW5zaWduZWQgY2hhciBjaXBoZXJ0 ZXh0W0JJR19URVNUX1NJWkVdOworICAgIHVuc2lnbmVkIGNoYXIgY2hlY2t0ZXh0W0JJR19U RVNUX1NJWkVdOwogCi0gICAgLyogTm93IGNoZWNrIGVuY3J5cHQgY2hhaW5pbmcgd29ya3Mg Ki8KICAgICBBRVNfc2V0X2VuY3J5cHRfa2V5KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtl eSk7CiAgICAgbWVtY3B5KGl2LCBzYXZlZF9pdiwgc2l6ZW9mIGl2KTsKICAgICBBRVNfaWdl X2VuY3J5cHQocGxhaW50ZXh0LCBjaXBoZXJ0ZXh0LCBURVNUX1NJWkUgLyAyLCAma2V5LCBp diwKQEAgLTI4MCwxNCArMjY1LDE2IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikKICAgICBtZW1jcHkoaXYsIHNhdmVkX2l2LCBzaXplb2YgaXYpOwogICAgIEFFU19pZ2Vf ZW5jcnlwdChjaXBoZXJ0ZXh0LCBjaGVja3RleHQsIFRFU1RfU0laRSwgJmtleSwgaXYsIEFF U19ERUNSWVBUKTsKIAotICAgIGlmIChtZW1jbXAoY2hlY2t0ZXh0LCBwbGFpbnRleHQsIFRF U1RfU0laRSkpIHsKLSAgICAgICAgcHJpbnRmKCJDaGFpbmVkIGVuY3J5cHQrZGVjcnlwdCBk b2Vzbid0IG1hdGNoXG4iKTsKLSAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJQbGFpbnRleHQi LCBwbGFpbnRleHQsIFRFU1RfU0laRSk7Ci0gICAgICAgIGhleGR1bXAoc3Rkb3V0LCAiQ2hl Y2t0ZXh0IiwgY2hlY2t0ZXh0LCBURVNUX1NJWkUpOwotICAgICAgICArK2VycjsKLSAgICB9 CisgICAgcmV0dXJuIFRFU1RfbWVtX2VxKGNoZWNrdGV4dCwgVEVTVF9TSVpFLCBwbGFpbnRl eHQsIFRFU1RfU0laRSk7Cit9CisKK3N0YXRpYyBpbnQgdGVzdF9pZ2VfZGVjX2NoYWluaW5n KHZvaWQpCit7CisgICAgQUVTX0tFWSBrZXk7CisgICAgdW5zaWduZWQgY2hhciBpdltBRVNf QkxPQ0tfU0laRSAqIDRdOworICAgIHVuc2lnbmVkIGNoYXIgY2lwaGVydGV4dFtCSUdfVEVT VF9TSVpFXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNoZWNrdGV4dFtCSUdfVEVTVF9TSVpFXTsK IAotICAgIC8qIEFuZCBjaGVjayBkZWNyeXB0IGNoYWluaW5nICovCiAgICAgQUVTX3NldF9l bmNyeXB0X2tleShya2V5LCA4ICogc2l6ZW9mIHJrZXksICZrZXkpOwogICAgIG1lbWNweShp diwgc2F2ZWRfaXYsIHNpemVvZiBpdik7CiAgICAgQUVTX2lnZV9lbmNyeXB0KHBsYWludGV4 dCwgY2lwaGVydGV4dCwgVEVTVF9TSVpFIC8gMiwgJmtleSwgaXYsCkBAIC0zMDQsMTQgKzI5 MSwyMCBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgICAgICAg ICAgICAgIGNoZWNrdGV4dCArIFRFU1RfU0laRSAvIDIsIFRFU1RfU0laRSAvIDIsICZrZXks IGl2LAogICAgICAgICAgICAgICAgICAgICBBRVNfREVDUllQVCk7CiAKLSAgICBpZiAobWVt Y21wKGNoZWNrdGV4dCwgcGxhaW50ZXh0LCBURVNUX1NJWkUpKSB7Ci0gICAgICAgIHByaW50 ZigiQ2hhaW5lZCBlbmNyeXB0K2NoYWluZWQgZGVjcnlwdCBkb2Vzbid0IG1hdGNoXG4iKTsK LSAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJQbGFpbnRleHQiLCBwbGFpbnRleHQsIFRFU1Rf U0laRSk7Ci0gICAgICAgIGhleGR1bXAoc3Rkb3V0LCAiQ2hlY2t0ZXh0IiwgY2hlY2t0ZXh0 LCBURVNUX1NJWkUpOwotICAgICAgICArK2VycjsKLSAgICB9CisgICAgcmV0dXJuIFRFU1Rf bWVtX2VxKGNoZWNrdGV4dCwgVEVTVF9TSVpFLCBwbGFpbnRleHQsIFRFU1RfU0laRSk7Cit9 CisKK3N0YXRpYyBpbnQgdGVzdF9pZ2VfZ2FyYmxlX2ZvcndhcmRzKHZvaWQpCit7CisgICAg QUVTX0tFWSBrZXk7CisgICAgdW5zaWduZWQgY2hhciBpdltBRVNfQkxPQ0tfU0laRSAqIDRd OworICAgIHVuc2lnbmVkIGNoYXIgY2lwaGVydGV4dFtCSUdfVEVTVF9TSVpFXTsKKyAgICB1 bnNpZ25lZCBjaGFyIGNoZWNrdGV4dFtCSUdfVEVTVF9TSVpFXTsKKyAgICB1bnNpZ25lZCBp bnQgbjsKKyAgICBpbnQgdGVzdHJlc3VsdCA9IDE7CisgICAgY29uc3Qgc2l6ZV90IGN0c2l6 ZSA9IHNpemVvZihjaGVja3RleHQpOworICAgIHNpemVfdCBtYXRjaGVzOwogCi0gICAgLyog bWFrZSBzdXJlIGdhcmJsZSBleHRlbmRzIGZvcndhcmRzIG9ubHkgKi8KICAgICBBRVNfc2V0 X2VuY3J5cHRfa2V5KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtleSk7CiAgICAgbWVtY3B5 KGl2LCBzYXZlZF9pdiwgc2l6ZW9mIGl2KTsKICAgICBBRVNfaWdlX2VuY3J5cHQocGxhaW50 ZXh0LCBjaXBoZXJ0ZXh0LCBzaXplb2YgcGxhaW50ZXh0LCAma2V5LCBpdiwKQEAgLTMyOSwy NiArMzIyLDI0IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKICAgICAgICAg aWYgKGNoZWNrdGV4dFtuXSA9PSBwbGFpbnRleHRbbl0pCiAgICAgICAgICAgICArK21hdGNo ZXM7CiAKLSAgICBpZiAobWF0Y2hlcyA+IHNpemVvZiBjaGVja3RleHQgLyAyICsgc2l6ZW9m IGNoZWNrdGV4dCAvIDEwMCkgewotICAgICAgICBwcmludGYoIk1vcmUgdGhhbiA1MSUlIG1h dGNoZXMgYWZ0ZXIgZ2FyYmxpbmdcbiIpOwotICAgICAgICArK2VycjsKLSAgICB9Ci0KLSAg ICBpZiAobWF0Y2hlcyA8IHNpemVvZiBjaGVja3RleHQgLyAyKSB7Ci0gICAgICAgIHByaW50 ZigiR2FyYmxlIGV4dGVuZHMgYmFja3dhcmRzIVxuIik7Ci0gICAgICAgICsrZXJyOwotICAg IH0KLQotICAgIC8qIEJpLWRpcmVjdGlvbmFsIElHRSAqLworICAgIC8qIEZhaWwgaWYgdGhl cmUgaXMgbW9yZSB0aGFuIDUxJSBtYXRjaGluZyBieXRlcyAqLworICAgIGlmICghVEVTVF9z aXplX3RfbGUobWF0Y2hlcywgY3RzaXplIC8gMiArIGN0c2l6ZSAvIDEwMCkpCisgICAgICAg IHRlc3RyZXN1bHQgPSAwOwogCi0gICAgLyoKLSAgICAgKiBOb3RlIHRoYXQgd2UgZG9uJ3Qg aGF2ZSB0byByZWNvdmVyIHRoZSBJViwgYmVjYXVzZSBjaGFpbmluZyBpc24ndAotICAgICAq LwotICAgIC8qIHBvc3NpYmxlIHdpdGggYmlJR0UsIHNvIHRoZSBJViBpcyBub3QgdXBkYXRl ZC4gKi8KKyAgICAvKiBGYWlsIGlmIHRoZSBnYXJibGUgZ29lcyBiYWNrd2FyZHMgKi8KKyAg ICBpZiAoIVRFU1Rfc2l6ZV90X2d0KG1hdGNoZXMsIGN0c2l6ZSAvIDIpKQorICAgICAgICB0 ZXN0cmVzdWx0ID0gMDsKKyAgICByZXR1cm4gdGVzdHJlc3VsdDsKK30KIAotICAgIFJBTkRf Ynl0ZXMocmtleTIsIHNpemVvZiBya2V5Mik7CitzdGF0aWMgaW50IHRlc3RfYmlfaWdlX2Vu Y19kZWModm9pZCkKK3sKKyAgICBBRVNfS0VZIGtleSwga2V5MjsKKyAgICB1bnNpZ25lZCBj aGFyIGl2W0FFU19CTE9DS19TSVpFICogNF07CisgICAgdW5zaWduZWQgY2hhciBjaXBoZXJ0 ZXh0W0JJR19URVNUX1NJWkVdOworICAgIHVuc2lnbmVkIGNoYXIgY2hlY2t0ZXh0W0JJR19U RVNUX1NJWkVdOwogCi0gICAgLyogU3RyYWlnaHQgZW5jcnlwdC9kZWNyeXB0ICovCisgICAg bWVtY3B5KGl2LCBzYXZlZF9pdiwgc2l6ZW9mIGl2KTsKICAgICBBRVNfc2V0X2VuY3J5cHRf a2V5KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtleSk7CiAgICAgQUVTX3NldF9lbmNyeXB0 X2tleShya2V5MiwgOCAqIHNpemVvZiBya2V5MiwgJmtleTIpOwogICAgIEFFU19iaV9pZ2Vf ZW5jcnlwdChwbGFpbnRleHQsIGNpcGhlcnRleHQsIFRFU1RfU0laRSwgJmtleSwgJmtleTIs IGl2LApAQCAtMzU5LDE0ICszNTAsMTggQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiph cmd2KQogICAgIEFFU19iaV9pZ2VfZW5jcnlwdChjaXBoZXJ0ZXh0LCBjaGVja3RleHQsIFRF U1RfU0laRSwgJmtleSwgJmtleTIsIGl2LAogICAgICAgICAgICAgICAgICAgICAgICBBRVNf REVDUllQVCk7CiAKLSAgICBpZiAobWVtY21wKGNoZWNrdGV4dCwgcGxhaW50ZXh0LCBURVNU X1NJWkUpKSB7Ci0gICAgICAgIHByaW50ZigiRW5jcnlwdCtkZWNyeXB0IGRvZXNuJ3QgbWF0 Y2hcbiIpOwotICAgICAgICBoZXhkdW1wKHN0ZG91dCwgIlBsYWludGV4dCIsIHBsYWludGV4 dCwgVEVTVF9TSVpFKTsKLSAgICAgICAgaGV4ZHVtcChzdGRvdXQsICJDaGVja3RleHQiLCBj aGVja3RleHQsIFRFU1RfU0laRSk7Ci0gICAgICAgICsrZXJyOwotICAgIH0KKyAgICByZXR1 cm4gVEVTVF9tZW1fZXEoY2hlY2t0ZXh0LCBURVNUX1NJWkUsIHBsYWludGV4dCwgVEVTVF9T SVpFKTsKK30KKworc3RhdGljIGludCB0ZXN0X2JpX2lnZV9nYXJibGUxKHZvaWQpCit7Cisg ICAgQUVTX0tFWSBrZXksIGtleTI7CisgICAgdW5zaWduZWQgY2hhciBpdltBRVNfQkxPQ0tf U0laRSAqIDRdOworICAgIHVuc2lnbmVkIGNoYXIgY2lwaGVydGV4dFtCSUdfVEVTVF9TSVpF XTsKKyAgICB1bnNpZ25lZCBjaGFyIGNoZWNrdGV4dFtCSUdfVEVTVF9TSVpFXTsKKyAgICB1 bnNpZ25lZCBpbnQgbjsKKyAgICBzaXplX3QgbWF0Y2hlczsKIAotICAgIC8qIG1ha2Ugc3Vy ZSBnYXJibGUgZXh0ZW5kcyBib3RoIHdheXMgKi8KICAgICBBRVNfc2V0X2VuY3J5cHRfa2V5 KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtleSk7CiAgICAgQUVTX3NldF9lbmNyeXB0X2tl eShya2V5MiwgOCAqIHNpemVvZiBya2V5MiwgJmtleTIpOwogICAgIEFFU19pZ2VfZW5jcnlw dChwbGFpbnRleHQsIGNpcGhlcnRleHQsIHNpemVvZiBwbGFpbnRleHQsICZrZXksIGl2LApA QCAtMzg0LDEyICszNzksMTkgQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQog ICAgICAgICBpZiAoY2hlY2t0ZXh0W25dID09IHBsYWludGV4dFtuXSkKICAgICAgICAgICAg ICsrbWF0Y2hlczsKIAotICAgIGlmIChtYXRjaGVzID4gc2l6ZW9mIGNoZWNrdGV4dCAvIDEw MCkgewotICAgICAgICBwcmludGYoIk1vcmUgdGhhbiAxJSUgbWF0Y2hlcyBhZnRlciBiaWRp cmVjdGlvbmFsIGdhcmJsaW5nXG4iKTsKLSAgICAgICAgKytlcnI7Ci0gICAgfQorICAgIC8q IEZhaWwgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIDElIG1hdGNoaW5nIGJ5dGVzICovCisgICAg cmV0dXJuIFRFU1Rfc2l6ZV90X2xlKG1hdGNoZXMsIHNpemVvZiBjaGVja3RleHQgLyAxMDAp OworfQorCitzdGF0aWMgaW50IHRlc3RfYmlfaWdlX2dhcmJsZTIodm9pZCkKK3sKKyAgICBB RVNfS0VZIGtleSwga2V5MjsKKyAgICB1bnNpZ25lZCBjaGFyIGl2W0FFU19CTE9DS19TSVpF ICogNF07CisgICAgdW5zaWduZWQgY2hhciBjaXBoZXJ0ZXh0W0JJR19URVNUX1NJWkVdOwor ICAgIHVuc2lnbmVkIGNoYXIgY2hlY2t0ZXh0W0JJR19URVNUX1NJWkVdOworICAgIHVuc2ln bmVkIGludCBuOworICAgIHNpemVfdCBtYXRjaGVzOwogCi0gICAgLyogbWFrZSBzdXJlIGdh cmJsZSBleHRlbmRzIGJvdGggd2F5cyAoMikgKi8KICAgICBBRVNfc2V0X2VuY3J5cHRfa2V5 KHJrZXksIDggKiBzaXplb2YgcmtleSwgJmtleSk7CiAgICAgQUVTX3NldF9lbmNyeXB0X2tl eShya2V5MiwgOCAqIHNpemVvZiBya2V5MiwgJmtleTIpOwogICAgIEFFU19pZ2VfZW5jcnlw dChwbGFpbnRleHQsIGNpcGhlcnRleHQsIHNpemVvZiBwbGFpbnRleHQsICZrZXksIGl2LApA QCAtNDA3LDEyICs0MDksMTkgQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQog ICAgICAgICBpZiAoY2hlY2t0ZXh0W25dID09IHBsYWludGV4dFtuXSkKICAgICAgICAgICAg ICsrbWF0Y2hlczsKIAotICAgIGlmIChtYXRjaGVzID4gc2l6ZW9mIGNoZWNrdGV4dCAvIDEw MCkgewotICAgICAgICBwcmludGYoIk1vcmUgdGhhbiAxJSUgbWF0Y2hlcyBhZnRlciBiaWRp cmVjdGlvbmFsIGdhcmJsaW5nICgyKVxuIik7Ci0gICAgICAgICsrZXJyOwotICAgIH0KKyAg ICAvKiBGYWlsIGlmIHRoZXJlIGlzIG1vcmUgdGhhbiAxJSBtYXRjaGluZyBieXRlcyAqLwor ICAgIHJldHVybiBURVNUX3NpemVfdF9sZShtYXRjaGVzLCBzaXplb2YgY2hlY2t0ZXh0IC8g MTAwKTsKK30KKworc3RhdGljIGludCB0ZXN0X2JpX2lnZV9nYXJibGUzKHZvaWQpCit7Cisg ICAgQUVTX0tFWSBrZXksIGtleTI7CisgICAgdW5zaWduZWQgY2hhciBpdltBRVNfQkxPQ0tf U0laRSAqIDRdOworICAgIHVuc2lnbmVkIGNoYXIgY2lwaGVydGV4dFtCSUdfVEVTVF9TSVpF XTsKKyAgICB1bnNpZ25lZCBjaGFyIGNoZWNrdGV4dFtCSUdfVEVTVF9TSVpFXTsKKyAgICB1 bnNpZ25lZCBpbnQgbjsKKyAgICBzaXplX3QgbWF0Y2hlczsKIAotICAgIC8qIG1ha2Ugc3Vy ZSBnYXJibGUgZXh0ZW5kcyBib3RoIHdheXMgKDMpICovCiAgICAgQUVTX3NldF9lbmNyeXB0 X2tleShya2V5LCA4ICogc2l6ZW9mIHJrZXksICZrZXkpOwogICAgIEFFU19zZXRfZW5jcnlw dF9rZXkocmtleTIsIDggKiBzaXplb2YgcmtleTIsICZrZXkyKTsKICAgICBBRVNfaWdlX2Vu Y3J5cHQocGxhaW50ZXh0LCBjaXBoZXJ0ZXh0LCBzaXplb2YgcGxhaW50ZXh0LCAma2V5LCBp diwKQEAgLTQzMCwxMiArNDM5LDI1IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikKICAgICAgICAgaWYgKGNoZWNrdGV4dFtuXSA9PSBwbGFpbnRleHRbbl0pCiAgICAgICAg ICAgICArK21hdGNoZXM7CiAKLSAgICBpZiAobWF0Y2hlcyA+IHNpemVvZiBjaGVja3RleHQg LyAxMDApIHsKLSAgICAgICAgcHJpbnRmKCJNb3JlIHRoYW4gMSUlIG1hdGNoZXMgYWZ0ZXIg YmlkaXJlY3Rpb25hbCBnYXJibGluZyAoMylcbiIpOwotICAgICAgICArK2VycjsKLSAgICB9 Ci0KLSAgICBlcnIgKz0gcnVuX3Rlc3RfdmVjdG9ycygpOworICAgIC8qIEZhaWwgaWYgdGhl cmUgaXMgbW9yZSB0aGFuIDElIG1hdGNoaW5nIGJ5dGVzICovCisgICAgcmV0dXJuIFRFU1Rf c2l6ZV90X2xlKG1hdGNoZXMsIHNpemVvZiBjaGVja3RleHQgLyAxMDApOworfQogCi0gICAg cmV0dXJuIGVycjsKK3ZvaWQgcmVnaXN0ZXJfdGVzdHModm9pZCkKK3sKKyAgICBSQU5EX2J5 dGVzKHJrZXksIHNpemVvZiBya2V5KTsKKyAgICBSQU5EX2J5dGVzKHJrZXkyLCBzaXplb2Yg cmtleTIpOworICAgIFJBTkRfYnl0ZXMocGxhaW50ZXh0LCBzaXplb2YgcGxhaW50ZXh0KTsK KyAgICBSQU5EX2J5dGVzKHNhdmVkX2l2LCBzaXplb2Ygc2F2ZWRfaXYpOworCisgICAgQURE X1RFU1QodGVzdF9pZ2VfZW5jX2RlYyk7CisgICAgQUREX1RFU1QodGVzdF9pZ2VfZW5jX2No YWluaW5nKTsKKyAgICBBRERfVEVTVCh0ZXN0X2lnZV9kZWNfY2hhaW5pbmcpOworICAgIEFE RF9URVNUKHRlc3RfaWdlX2dhcmJsZV9mb3J3YXJkcyk7CisgICAgQUREX1RFU1QodGVzdF9i aV9pZ2VfZW5jX2RlYyk7CisgICAgQUREX1RFU1QodGVzdF9iaV9pZ2VfZ2FyYmxlMSk7Cisg ICAgQUREX1RFU1QodGVzdF9iaV9pZ2VfZ2FyYmxlMik7CisgICAgQUREX1RFU1QodGVzdF9i aV9pZ2VfZ2FyYmxlMyk7CisgICAgQUREX0FMTF9URVNUUyh0ZXN0X2lnZV92ZWN0b3JzLCBP U1NMX05FTEVNKGlnZV90ZXN0X3ZlY3RvcnMpKTsKKyAgICBBRERfQUxMX1RFU1RTKHRlc3Rf YmlfaWdlX3ZlY3RvcnMsIE9TU0xfTkVMRU0oYmlfaWdlX3Rlc3RfdmVjdG9ycykpOwogfQpk aWZmIC0tZ2l0IGEvdGVzdC9yZWNpcGVzLzcwLXRlc3RfdGxzMTNtZXNzYWdlcy50IGIvdGVz dC9yZWNpcGVzLzcwLXRlc3RfdGxzMTNtZXNzYWdlcy50CmluZGV4IGM0ZTIwYjcuLmM5NjAz ZGUgMTAwNjQ0Ci0tLSBhL3Rlc3QvcmVjaXBlcy83MC10ZXN0X3RsczEzbWVzc2FnZXMudAor KysgYi90ZXN0L3JlY2lwZXMvNzAtdGVzdF90bHMxM21lc3NhZ2VzLnQKQEAgLTEyNiw2ICsx MjYsOCBAQCAkRU5We0NUTE9HX0ZJTEV9ID0gc3JjdG9wX2ZpbGUoInRlc3QiLCAiY3QiLCAi bG9nX2xpc3QuY29uZiIpOwogCiAgICAgW1RMU1Byb3h5OjpNZXNzYWdlOjpNVF9DRVJUSUZJ Q0FURSwgVExTUHJveHk6Ok1lc3NhZ2U6OkVYVF9TVEFUVVNfUkVRVUVTVCwKICAgICAgICAg Y2hlY2toYW5kc2hha2U6OlNUQVRVU19SRVFVRVNUX1NSVl9FWFRFTlNJT05dLAorICAgIFtU TFNQcm94eTo6TWVzc2FnZTo6TVRfQ0VSVElGSUNBVEUsIFRMU1Byb3h5OjpNZXNzYWdlOjpF WFRfU0NULAorICAgICAgICBjaGVja2hhbmRzaGFrZTo6U0NUX1NSVl9FWFRFTlNJT05dLAog CiAgICAgWzAsMCwwXQogKTsKQEAgLTI1NywyNSArMjU5LDI5IEBAIGNoZWNraGFuZHNoYWtl KCRwcm94eSwgY2hlY2toYW5kc2hha2U6OkRFRkFVTFRfSEFORFNIQUtFLAogICAgICAgICAg ICAgICAgfCBjaGVja2hhbmRzaGFrZTo6QUxQTl9TUlZfRVhURU5TSU9OLAogICAgICAgICAg ICAgICAgIkFMUE4gaGFuZHNoYWtlIHRlc3QiKTsKIAotI1Rlc3QgMTM6IFNDVCBoYW5kc2hh a2UgKGNsaWVudCByZXF1ZXN0IG9ubHkpCi0jVE9ETyhUTFMxLjMpOiBUaGlzIG9ubHkgY2hl Y2tzIHRoYXQgdGhlIGNsaWVudCBzaWRlIGV4dGVuc2lvbiBhcHBlYXJzLiBUaGUKLSNTQ1Qg ZXh0ZW5zaW9uIGlzIHVudXN1YWwgaW4gdGhhdCB3ZSBoYXZlIG5vIGJ1aWx0LWluIHNlcnZl ciBzaWRlIGltcGxlbWVudGF0aW9uCi0jVGhlIHNlcnZlciBzaWRlIGltcGxlbWVudGF0aW9u IGNhbiBub21yYWxseSBiZSBhZGRlZCB1c2luZyB0aGUgY3VzdG9tCi0jZXh0ZW5zaW9ucyBm cmFtZXdvcmsgKGUuZy4gYnkgdXNpbmcgdGhlICItc2VydmVyaW5mbyIgc19zZXJ2ZXIgb3B0 aW9uKS4gSG93ZXZlcgotI2N1cnJlbnRseSB3ZSBvbmx5IHN1cHBvcnQgPD0gVExTMS4yIGZv ciBjdXN0b20gZXh0ZW5zaW9ucyBiZWNhdXNlIHRoZSBleGlzdGluZwotI2ZyYW1ld29yayBh bmQgQVBJIGhhcyBubyBrbm93bGVkZ2Ugb2YgdGhlIFRMUzEuMyBtZXNzYWdlcwotJHByb3h5 LT5jbGVhcigpOwotI05vdGU6IC1jdCBhbHNvIHNlbmRzIHN0YXR1c19yZXF1ZXN0Ci0kcHJv eHktPmNsaWVudGZsYWdzKCItY3QiKTsKLSRwcm94eS0+c2VydmVyZmxhZ3MoIi1zdGF0dXNf ZmlsZSAiCi0gICAgICAgICAgICAgICAgICAgIC5zcmN0b3BfZmlsZSgidGVzdCIsICJyZWNp cGVzIiwgIm9jc3AtcmVzcG9uc2UuZGVyIikpOwotJHByb3h5LT5zdGFydCgpOwotY2hlY2to YW5kc2hha2UoJHByb3h5LCBjaGVja2hhbmRzaGFrZTo6REVGQVVMVF9IQU5EU0hBS0UsCi0g ICAgICAgICAgICAgICBjaGVja2hhbmRzaGFrZTo6REVGQVVMVF9FWFRFTlNJT05TCi0gICAg ICAgICAgICAgICB8IGNoZWNraGFuZHNoYWtlOjpTQ1RfQ0xJX0VYVEVOU0lPTgotICAgICAg ICAgICAgICAgfCBjaGVja2hhbmRzaGFrZTo6U1RBVFVTX1JFUVVFU1RfQ0xJX0VYVEVOU0lP TgotICAgICAgICAgICAgICAgfCBjaGVja2hhbmRzaGFrZTo6U1RBVFVTX1JFUVVFU1RfU1JW X0VYVEVOU0lPTiwKLSAgICAgICAgICAgICAgICJTQ1QgaGFuZHNoYWtlIHRlc3QiKTsKK1NL SVA6IHsKKyAgICBza2lwICJObyBDVCwgRUMgb3IgT0NTUCBzdXBwb3J0IGluIHRoaXMgT3Bl blNTTCBidWlsZCIsIDEKKyAgICAgICAgaWYgZGlzYWJsZWQoImN0IikgfHwgZGlzYWJsZWQo ImVjIikgfHwgZGlzYWJsZWQoIm9jc3AiKTsKKworICAgICNUZXN0IDEzOiBTQ1QgaGFuZHNo YWtlIChjbGllbnQgcmVxdWVzdCBvbmx5KQorICAgICRwcm94eS0+Y2xlYXIoKTsKKyAgICAj Tm90ZTogLWN0IGFsc28gc2VuZHMgc3RhdHVzX3JlcXVlc3QKKyAgICAkcHJveHktPmNsaWVu dGZsYWdzKCItY3QiKTsKKyAgICAkcHJveHktPnNlcnZlcmZsYWdzKCItc3RhdHVzX2ZpbGUg IgorICAgICAgICAgICAgICAgICAgICAgICAgLnNyY3RvcF9maWxlKCJ0ZXN0IiwgInJlY2lw ZXMiLCAib2NzcC1yZXNwb25zZS5kZXIiKQorICAgICAgICAgICAgICAgICAgICAgICAgLiIg LXNlcnZlcmluZm8gIi5zcmN0b3BfZmlsZSgidGVzdCIsICJzZXJ2ZXJpbmZvMi5wZW0iKSk7 CisgICAgJHByb3h5LT5zdGFydCgpOworICAgIGNoZWNraGFuZHNoYWtlKCRwcm94eSwgY2hl Y2toYW5kc2hha2U6OkRFRkFVTFRfSEFORFNIQUtFLAorICAgICAgICAgICAgICAgICAgIGNo ZWNraGFuZHNoYWtlOjpERUZBVUxUX0VYVEVOU0lPTlMKKyAgICAgICAgICAgICAgICAgICB8 IGNoZWNraGFuZHNoYWtlOjpTQ1RfQ0xJX0VYVEVOU0lPTgorICAgICAgICAgICAgICAgICAg IHwgY2hlY2toYW5kc2hha2U6OlNDVF9TUlZfRVhURU5TSU9OCisgICAgICAgICAgICAgICAg ICAgfCBjaGVja2hhbmRzaGFrZTo6U1RBVFVTX1JFUVVFU1RfQ0xJX0VYVEVOU0lPTgorICAg ICAgICAgICAgICAgICAgIHwgY2hlY2toYW5kc2hha2U6OlNUQVRVU19SRVFVRVNUX1NSVl9F WFRFTlNJT04sCisgICAgICAgICAgICAgICAgICAgIlNDVCBoYW5kc2hha2UgdGVzdCIpOwor fQorCisKKwogCiAjVGVzdCAxNDogSFJSIEhhbmRzaGFrZQogJHByb3h5LT5jbGVhcigpOwpk aWZmIC0tZ2l0IGEvdGVzdC9zZXJ2ZXJpbmZvMi5wZW0gYi90ZXN0L3NlcnZlcmluZm8yLnBl bQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi43OTJkNWMwCi0tLSAvZGV2 L251bGwKKysrIGIvdGVzdC9zZXJ2ZXJpbmZvMi5wZW0KQEAgLTAsMCArMSw4IEBACistLS0t LUJFR0lOIFNFUlZFUklORk9WMiBGT1IgQ1QtLS0tLQorQUFBUmdBQVNBUElBOEFCMkFPNUx2 YmQxem1DNjRVSnBINnZobm1hakQzNWZzSExZZ3dERWU0bDZxUDNMQUFBQgorV3hwK3lWa0FB QVFEQUVjd1JRSWhBTWhaN1NlMm9sWjM1TXF6ZTJObERzVzM1dHR5SXJSdUh5aTZGMEtsenNT cAorQWlCRFQ4WUxqTkNVQnlWckQ5amhvUmJVeSt0MzhmeDlXYk9XZ1JWeFo1eGsyd0IyQU4z ckhTdDZEVSttSUl1QgorcllGb2NINHVqcDBCMVZ5SWpUMFJ4TTIyN0w3TUFBQUJXeHAreDgw QUFBUURBRWN3UlFJZ0V6LzVTQytKQTVLbworMGl2eEdZZjVYQkNxamZjSXJwMkJwQ1Z4eVlB MnlzMENJUUMxa2NDZWlod3diaVZGVGpSOFVlY0xhQ2QxbDFpeAorbm9wWjlsamhHMDE4K2c9 PQorLS0tLS1FTkQgU0VSVkVSSU5GT1YyIEZPUiBDVC0tLS0tCmRpZmYgLS1naXQgYS90ZXN0 L3RsczEzc2VjcmV0c3Rlc3QuYyBiL3Rlc3QvdGxzMTNzZWNyZXRzdGVzdC5jCmluZGV4IDI5 MDRiYTkuLmRhY2NkN2MgMTAwNjQ0Ci0tLSBhL3Rlc3QvdGxzMTNzZWNyZXRzdGVzdC5jCisr KyBiL3Rlc3QvdGxzMTNzZWNyZXRzdGVzdC5jCkBAIC0zNCw3ICszNCw3IEBACiAgKiB0aG9z ZSwgZS5nLiBzZWUKICAqIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRob21zb24t dGxzLXRsczEzLXZlY3RvcnMtMDAudHh0LCBob3dldmVyIGF0CiAgKiB0aGUgdGltZSBvZiB3 cml0aW5nIHRoZXNlIGFyZSBub3Qgc3VpdGFibGUgYmVjYXVzZSB0aGV5IGFyZSBiYXNlZCBv bgotICogZHJhZnQgLTE2LCB3aGljaCB3b3JrcyBkaWZmZXJlbnRseSB0byB0aGUgZHJhZnQg LTE5IHZlY3RvcnMgYmVsb3cuCisgKiBkcmFmdCAtMTYsIHdoaWNoIHdvcmtzIGRpZmZlcmVu dGx5IHRvIHRoZSBkcmFmdCAtMjAgdmVjdG9ycyBiZWxvdy4KICAqLwogCiBzdGF0aWMgdW5z aWduZWQgY2hhciBoc19zdGFydF9oYXNoW10gPSB7CkBAIC02Miw4MyArNjIsODMgQEAgc3Rh dGljIHVuc2lnbmVkIGNoYXIgZWNkaGVfc2VjcmV0W10gPSB7CiB9OwogCiBzdGF0aWMgdW5z aWduZWQgY2hhciBoYW5kc2hha2Vfc2VjcmV0W10gPSB7Ci0weGE0LCAweGM2LCAweDJlLCAw eDFjLCAweDNjLCAweGI4LCAweDBhLCAweGFlLCAweDM0LCAweDM0LCAweDBkLCAweGI4LCAw eGZiLAotMHgwZCwgMHhkNSwgMHgwZCwgMHgyZCwgMHgyZiwgMHgwOCwgMHhhNCwgMHg1NCwg MHg2YiwgMHhiYiwgMHgyZSwgMHg2MCwgMHhjNiwKLTB4NTMsIDB4YWMsIDB4YjMsIDB4Y2Es IDB4ZjIsIDB4ODcKKzB4ZjUsIDB4NTEsIDB4ZDAsIDB4YmQsIDB4OWUsIDB4NmEsIDB4YzAs IDB4OTUsIDB4NWYsIDB4OGUsIDB4YWUsIDB4YjYsIDB4MjgsCisweDJlLCAweDhkLCAweDll LCAweGYzLCAweGQ0LCAweDA4LCAweDU3LCAweDgxLCAweGJjLCAweDlkLCAweDgwLCAweDkx LCAweDhhLAorMHg4MSwgMHgzMywgMHg4NiwgMHg1OCwgMHg3ZiwgMHg0NgogfTsKIAotc3Rh dGljIGNvbnN0IGNoYXIgKmNsaWVudF9odHNfbGFiZWwgPSAiY2xpZW50IGhhbmRzaGFrZSB0 cmFmZmljIHNlY3JldCI7CitzdGF0aWMgY29uc3QgY2hhciAqY2xpZW50X2h0c19sYWJlbCA9 ICJjIGhzIHRyYWZmaWMiOwogCiBzdGF0aWMgdW5zaWduZWQgY2hhciBjbGllbnRfaHRzW10g PSB7Ci0weGQ3LCAweDU4LCAweDlmLCAweDEwLCAweGE4LCAweDMwLCAweGYzLCAweDg1LCAw eDYzLCAweDZmLCAweGQ5LCAweGIwLCAweDYxLAotMHhkNSwgMHgyMCwgMHgxOSwgMHhiMSwg MHg0NSwgMHg5NiwgMHg4MiwgMHgyNCwgMHg4ZSwgMHgzNiwgMHg0NSwgMHhmNywgMHg1YSwK LTB4ZDcsIDB4MmYsIDB4MzEsIDB4ZWMsIDB4NTcsIDB4ZjcKKzB4NjEsIDB4N2IsIDB4MzUs IDB4MDcsIDB4NmIsIDB4OWQsIDB4MGUsIDB4MDgsIDB4Y2YsIDB4NzMsIDB4MWQsIDB4OTQs IDB4YTgsCisweDY2LCAweDE0LCAweDc4LCAweDQxLCAweDA5LCAweGVmLCAweDI1LCAweDU1 LCAweDUxLCAweDkyLCAweDFkLCAweGQ0LCAweDZlLAorMHgwNCwgMHgwMSwgMHgzNSwgMHhj ZiwgMHg0NiwgMHhhYgogfTsKIAogc3RhdGljIHVuc2lnbmVkIGNoYXIgY2xpZW50X2h0c19r ZXlbXSA9IHsKLTB4Y2MsIDB4OGIsIDB4ZGEsIDB4YmYsIDB4ODMsIDB4NzQsIDB4MmQsIDB4 ZjQsIDB4NTMsIDB4NDQsIDB4ZmYsIDB4YmMsIDB4YTQsCi0weDQzLCAweGM4LCAweDJhCisw eDYyLCAweGQwLCAweGRkLCAweDAwLCAweGY2LCAweDk2LCAweDE5LCAweGQzLCAweGI4LCAw eDE5LCAweDNhLCAweGI0LCAweGEwLAorMHg5NSwgMHg4NSwgMHhhNwogfTsKIAogc3RhdGlj IHVuc2lnbmVkIGNoYXIgY2xpZW50X2h0c19pdltdID0gewotMHhhNCwgMHg4MywgMHg0Niwg MHgxMSwgMHhjMiwgMHg3OCwgMHhlYSwgMHgwZiwgMHg5NCwgMHg1MiwgMHgxZCwgMHhjYQor MHhmZiwgMHhmNywgMHg1ZCwgMHhmNSwgMHhhZCwgMHgzNSwgMHhkNSwgMHhjYiwgMHgzYywg MHg1MywgMHhmMywgMHhhOQogfTsKIAotc3RhdGljIGNvbnN0IGNoYXIgKnNlcnZlcl9odHNf bGFiZWwgPSAic2VydmVyIGhhbmRzaGFrZSB0cmFmZmljIHNlY3JldCI7CitzdGF0aWMgY29u c3QgY2hhciAqc2VydmVyX2h0c19sYWJlbCA9ICJzIGhzIHRyYWZmaWMiOwogCiBzdGF0aWMg dW5zaWduZWQgY2hhciBzZXJ2ZXJfaHRzW10gPSB7Ci0weGJhLCAweDdjLCAweDNiLCAweDc0 LCAweDBkLCAweDFlLCAweDg0LCAweDgyLCAweGQ2LCAweDZmLCAweDNlLCAweDVlLCAweDFk LAotMHg2ZSwgMHgyNSwgMHhkYywgMHg4NywgMHgxZiwgMHg0OCwgMHg3NCwgMHgyZiwgMHg2 NSwgMHhhNCwgMHg0MCwgMHgzOSwgMHhkYSwKLTB4ZGMsIDB4MDIsIDB4MmEsIDB4MTYsIDB4 MTksIDB4NWMKKzB4ZmMsIDB4ZjcsIDB4ZGYsIDB4ZTYsIDB4NGYsIDB4YTIsIDB4YzAsIDB4 NGYsIDB4NjIsIDB4MzUsIDB4MzgsIDB4N2YsIDB4NDMsCisweDRlLCAweDAxLCAweDQyLCAw eDIzLCAweDM2LCAweGQ5LCAweGMwLCAweDM5LCAweGRlLCAweDY4LCAweDQ3LCAweGEwLCAw eGI5LAorMHhkZCwgMHhjZiwgMHgyOSwgMHhhOCwgMHg4NywgMHg1OQogfTsKIAogc3RhdGlj IHVuc2lnbmVkIGNoYXIgc2VydmVyX2h0c19rZXlbXSA9IHsKLTB4N2QsIDB4MjIsIDB4MmEs IDB4M2YsIDB4NzIsIDB4MzcsIDB4OTIsIDB4ZDksIDB4OTUsIDB4OWEsIDB4ZTEsIDB4NjYs IDB4MzIsCi0weDZmLCAweDBkLCAweGM5CisweDA0LCAweDY3LCAweGYzLCAweDE2LCAweGE4 LCAweDA1LCAweGI4LCAweGM0LCAweDk3LCAweGVlLCAweDY3LCAweDA0LCAweDdiLAorMHhi YywgMHhiYywgMHg1NAogfTsKIAogc3RhdGljIHVuc2lnbmVkIGNoYXIgc2VydmVyX2h0c19p dltdID0gewotMHhhMiwgMHg3MywgMHhjZCwgMHg0ZSwgMHgyMCwgMHhlNywgMHhlMSwgMHhl MywgMHhjYiwgMHgwZSwgMHgxOCwgMHg5ZQorMHhkZSwgMHg4MywgMHhhNywgMHgzZSwgMHg5 ZCwgMHg4MSwgMHg0YiwgMHgwNCwgMHhjNCwgMHg4YiwgMHg3OCwgMHgwOQogfTsKIAogc3Rh dGljIHVuc2lnbmVkIGNoYXIgbWFzdGVyX3NlY3JldFtdID0gewotMHg5YSwgMHgyZiwgMHgz NiwgMHhkYywgMHg2OCwgMHhhYiwgMHg4ZiwgMHgwNywgMHhlZiwgMHg0MSwgMHhlYSwgMHg2 MywgMHgzOSwKLTB4ZmMsIDB4NDYsIDB4NmIsIDB4MTEsIDB4MjQsIDB4ZDYsIDB4YmEsIDB4 NmIsIDB4OGEsIDB4OTIsIDB4NzQsIDB4NjEsIDB4ZDMsCi0weDY0LCAweDgyLCAweGMxLCAw eGM5LCAweGM3LCAweDBlCisweDM0LCAweDgzLCAweDgzLCAweDg0LCAweDY3LCAweDEyLCAw eGU3LCAweGZmLCAweDI0LCAweGU4LCAweDZlLCAweDcwLCAweDU2LAorMHg5NSwgMHgxNiwg MHg3MSwgMHg0MywgMHg3ZiwgMHgxOSwgMHhkNywgMHg4NSwgMHgwNiwgMHg5ZCwgMHg3NSwg MHg3MCwgMHg0OSwKKzB4NmUsIDB4NmMsIDB4YTQsIDB4ODEsIDB4ZjAsIDB4YjgKIH07CiAK LXN0YXRpYyBjb25zdCBjaGFyICpjbGllbnRfYXRzX2xhYmVsID0gImNsaWVudCBhcHBsaWNh dGlvbiB0cmFmZmljIHNlY3JldCI7CitzdGF0aWMgY29uc3QgY2hhciAqY2xpZW50X2F0c19s YWJlbCA9ICJjIGFwIHRyYWZmaWMiOwogCiBzdGF0aWMgdW5zaWduZWQgY2hhciBjbGllbnRf YXRzW10gPSB7Ci0weGMzLCAweDYwLCAweDVmLCAweGIzLCAweGM0LCAweDRiLCAweGMyLCAw eDI1LCAweGQyLCAweGFmLCAweDM2LCAweGFkLCAweDk5LAotMHhhMSwgMHhjZCwgMHhjZiwg MHg3MSwgMHhjNCwgMHhiOSwgMHhhMiwgMHgzZCwgMHhkMiwgMHgzZSwgMHhlNiwgMHhmZiwg MHhjYSwKLTB4MmMsIDB4NzEsIDB4ODYsIDB4M2QsIDB4MWYsIDB4ODUKKzB4YzEsIDB4NGEs IDB4NmQsIDB4NzksIDB4NzYsIDB4ZDgsIDB4MTAsIDB4MmIsIDB4NWEsIDB4MGMsIDB4OTks IDB4NTEsIDB4NDksCisweDNmLCAweGVlLCAweDg3LCAweGRjLCAweGFmLCAweGY4LCAweDJj LCAweDI0LCAweGNhLCAweGIyLCAweDE0LCAweGU4LCAweGJlLAorMHg3MSwgMHhhOCwgMHgy MCwgMHg2ZCwgMHhiZCwgMHhhNQogfTsKIAogc3RhdGljIHVuc2lnbmVkIGNoYXIgY2xpZW50 X2F0c19rZXlbXSA9IHsKLTB4M2EsIDB4MjUsIDB4MjMsIDB4MTIsIDB4ZGUsIDB4MGYsIDB4 NTMsIDB4YzcsIDB4YTAsIDB4YjIsIDB4Y2YsIDB4NzEsIDB4YjcsCi0weDFhLCAweDBkLCAw eGM3CisweGNjLCAweDlmLCAweDVmLCAweDk4LCAweDBiLCAweDVmLCAweDEwLCAweDMwLCAw eDZjLCAweGJhLCAweGQ3LCAweGJlLCAweDk4LAorMHhkNywgMHg1NywgMHgyZQogfTsKIAog c3RhdGljIHVuc2lnbmVkIGNoYXIgY2xpZW50X2F0c19pdltdID0gewotMHhiZCwgMHgwZCwg MHgzYywgMHgyNiwgMHg5ZCwgMHgyZCwgMHhhNiwgMHg1MiwgMHgxYiwgMHg4ZCwgMHg0NSwg MHhlZgorMHhiOCwgMHgwOSwgMHgyOSwgMHhlOCwgMHhkMCwgMHgyYywgMHg3MCwgMHhmNiwg MHgxMSwgMHg2MiwgMHhlZCwgMHg2YgogfTsKIAotc3RhdGljIGNvbnN0IGNoYXIgKnNlcnZl cl9hdHNfbGFiZWwgPSAic2VydmVyIGFwcGxpY2F0aW9uIHRyYWZmaWMgc2VjcmV0IjsKK3N0 YXRpYyBjb25zdCBjaGFyICpzZXJ2ZXJfYXRzX2xhYmVsID0gInMgYXAgdHJhZmZpYyI7CiAK IHN0YXRpYyB1bnNpZ25lZCBjaGFyIHNlcnZlcl9hdHNbXSA9IHsKLTB4MjcsIDB4OGQsIDB4 OTYsIDB4NzYsIDB4OTUsIDB4OWUsIDB4M2UsIDB4MzksIDB4YTQsIDB4YTksIDB4ZmMsIDB4 NDYsIDB4OWMsCi0weDMyLCAweDlmLCAweGUwLCAweDI5LCAweDUwLCAweDIyLCAweDQ1LCAw eDM5LCAweDgyLCAweGRkLCAweDFjLCAweGM1LCAweGZiLAotMHhhOSwgMHgwYSwgMHg2OCwg MHgyOSwgMHg0ZSwgMHg4MAorMHgyYywgMHg5MCwgMHg3NywgMHgzOCwgMHhkMywgMHhmOCwg MHgzNywgMHgwMiwgMHhkMSwgMHhlNCwgMHg1OSwgMHg4ZiwgMHg0OCwKKzB4NDgsIDB4NTMs IDB4MWQsIDB4OWYsIDB4OTMsIDB4NjUsIDB4NDksIDB4MWIsIDB4OWYsIDB4N2YsIDB4NTIs IDB4YzgsIDB4MjIsCisweDI5LCAweDBkLCAweDRjLCAweDIzLCAweDIxLCAweDkyCiB9Owog CiBzdGF0aWMgdW5zaWduZWQgY2hhciBzZXJ2ZXJfYXRzX2tleVtdID0gewotMHg3OCwgMHhi ZCwgMHhkNywgMHhjNiwgMHhiMCwgMHhmMSwgMHg1MCwgMHg1ZSwgMHhhZSwgMHg1NCwgMHhm ZiwgMHhhNSwgMHhmMiwKLTB4ZWQsIDB4MGIsIDB4NzcKKzB4MGMsIDB4YjIsIDB4OTUsIDB4 NjIsIDB4ZDgsIDB4ZDgsIDB4OGYsIDB4NDgsIDB4YjAsIDB4MmMsIDB4YmYsIDB4YmUsIDB4 ZDcsCisweGU2LCAweDJiLCAweGIzCiB9OwogCiBzdGF0aWMgdW5zaWduZWQgY2hhciBzZXJ2 ZXJfYXRzX2l2W10gPSB7Ci0weGIxLCAweDdiLCAweDFjLCAweGEyLCAweGNhLCAweGJlLCAw eGU0LCAweGFjLCAweGI1LCAweGYzLCAweDkxLCAweDdlCisweDBkLCAweGIyLCAweDhmLCAw eDk4LCAweDg1LCAweDg2LCAweGExLCAweGI3LCAweGU0LCAweGQ1LCAweGM2LCAweDljCiB9 OwogCiAvKiBNb2NrZWQgb3V0IGltcGxlbWVudGF0aW9ucyBvZiB2YXJpb3VzIGZ1bmN0aW9u cyAqLwpkaWZmIC0tZ2l0IGEvdXRpbC9UTFNQcm94eS9SZWNvcmQucG0gYi91dGlsL1RMU1By b3h5L1JlY29yZC5wbQppbmRleCA1OTI1MTE5Li44YzZlOTAxIDEwMDY0NAotLS0gYS91dGls L1RMU1Byb3h5L1JlY29yZC5wbQorKysgYi91dGlsL1RMU1Byb3h5L1JlY29yZC5wbQpAQCAt MzYsNyArMzYsNyBAQCBteSAlcmVjb3JkX3R5cGUgPSAoCiAKIHVzZSBjb25zdGFudCB7CiAg ICAgVkVSU19UTFNfMV80ID0+IDB4MDMwNSwKLSAgICBWRVJTX1RMU18xXzNfRFJBRlQgPT4g MHg3ZjEzLAorICAgIFZFUlNfVExTXzFfM19EUkFGVCA9PiAweDdmMTQsCiAgICAgVkVSU19U TFNfMV8zID0+IDB4MDMwNCwKICAgICBWRVJTX1RMU18xXzIgPT4gMHgwMzAzLAogICAgIFZF UlNfVExTXzFfMSA9PiAweDAzMDIsCmRpZmYgLS1naXQgYS91dGlsL2luZGVudC5wcm8gYi91 dGlsL2luZGVudC5wcm8KaW5kZXggODE1OTBlMS4uYzE0N2Y5NyAxMDA2NDQKLS0tIGEvdXRp bC9pbmRlbnQucHJvCisrKyBiL3V0aWwvaW5kZW50LnBybwpAQCAtMjIzLDggKzIyMywxMCBA QAogLVQgRVJSX1NUQVRFCiAtVCBFUlJfU1RSSU5HX0RBVEEKIC1UIEVTU19DRVJUX0lECist VCBFU1NfQ0VSVF9JRF9WMgogLVQgRVNTX0lTU1VFUl9TRVJJQUwKIC1UIEVTU19TSUdOSU5H X0NFUlQKKy1UIEVTU19TSUdOSU5HX0NFUlRfVjIKIC1UIEVWUF9BRVNfSE1BQ19TSEExCiAt VCBFVlBfQUVTX0hNQUNfU0hBMjU2CiAtVCBFVlBfQ0lQSEVSCkBAIC01MjUsNiArNTI3LDcg QEAKIC1UIFNUQUNLX09GX0VOR0lORV8KIC1UIFNUQUNLX09GX0VOR0lORV9DTEVBTlVQX0lU RU1fCiAtVCBTVEFDS19PRl9FU1NfQ0VSVF9JRF8KKy1UIFNUQUNLX09GX0VTU19DRVJUX0lE X1YyXwogLVQgU1RBQ0tfT0ZfRVZQX1BCRV9DVExfCiAtVCBTVEFDS19PRl9FVlBfUEtFWV9B U04xX01FVEhPRF8KIC1UIFNUQUNLX09GX0VWUF9QS0VZX01FVEhPRF8KZGlmZiAtLWdpdCBh L3V0aWwvbGliY3J5cHRvLm51bSBiL3V0aWwvbGliY3J5cHRvLm51bQppbmRleCBiMTM2YTcz Li4yZTgyMDQyIDEwMDY0NAotLS0gYS91dGlsL2xpYmNyeXB0by5udW0KKysrIGIvdXRpbC9s aWJjcnlwdG8ubnVtCkBAIC00Mjc2LDMgKzQyNzYsMTUgQEAgWDUwOV9DUkxfcHJpbnRfZXgg ICAgICAgICAgICAgICAgICAgICAgIDQyMTgJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOgogWDUw OV9TSUdfSU5GT19nZXQgICAgICAgICAgICAgICAgICAgICAgIDQyMTkJMV8xXzEJRVhJU1Q6 OkZVTkNUSU9OOgogWDUwOV9nZXRfc2lnbmF0dXJlX2luZm8gICAgICAgICAgICAgICAgIDQy MjAJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOgogWDUwOV9TSUdfSU5GT19zZXQgICAgICAgICAg ICAgICAgICAgICAgIDQyMjEJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOgorRVNTX0NFUlRfSURf VjJfZnJlZSAgICAgICAgICAgICAgICAgICAgIDQyMjIJMV8xXzEJRVhJU1Q6OkZVTkNUSU9O OlRTCitFU1NfU0lHTklOR19DRVJUX1YyX25ldyAgICAgICAgICAgICAgICAgNDIyMwkxXzFf MQlFWElTVDo6RlVOQ1RJT046VFMKK2QyaV9FU1NfU0lHTklOR19DRVJUX1YyICAgICAgICAg ICAgICAgICA0MjI0CTFfMV8xCUVYSVNUOjpGVU5DVElPTjpUUworaTJkX0VTU19DRVJUX0lE X1YyICAgICAgICAgICAgICAgICAgICAgIDQyMjUJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOlRT CitFU1NfQ0VSVF9JRF9WMl9kdXAgICAgICAgICAgICAgICAgICAgICAgNDIyNgkxXzFfMQlF WElTVDo6RlVOQ1RJT046VFMKK1RTX1JFU1BfQ1RYX3NldF9lc3NfY2VydF9pZF9kaWdlc3Qg ICAgICA0MjI3CTFfMV8xCUVYSVNUOjpGVU5DVElPTjpUUworZDJpX0VTU19DRVJUX0lEX1Yy ICAgICAgICAgICAgICAgICAgICAgIDQyMjgJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOlRTCitp MmRfRVNTX1NJR05JTkdfQ0VSVF9WMiAgICAgICAgICAgICAgICAgNDIyOQkxXzFfMQlFWElT VDo6RlVOQ1RJT046VFMKK1RTX0NPTkZfc2V0X2Vzc19jZXJ0X2lkX2RpZ2VzdCAgICAgICAg ICA0MjMwCTFfMV8xCUVYSVNUOjpGVU5DVElPTjpUUworRVNTX1NJR05JTkdfQ0VSVF9WMl9m cmVlICAgICAgICAgICAgICAgIDQyMzEJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOlRTCitFU1Nf U0lHTklOR19DRVJUX1YyX2R1cCAgICAgICAgICAgICAgICAgNDIzMgkxXzFfMQlFWElTVDo6 RlVOQ1RJT046VFMKK0VTU19DRVJUX0lEX1YyX25ldyAgICAgICAgICAgICAgICAgICAgICA0 MjMzCTFfMV8xCUVYSVNUOjpGVU5DVElPTjpUUwpkaWZmIC0tZ2l0IGEvdXRpbC9saWJzc2wu bnVtIGIvdXRpbC9saWJzc2wubnVtCmluZGV4IGExN2ViYmMuLmI0YWNiNWQgMTAwNjQ0Ci0t LSBhL3V0aWwvbGlic3NsLm51bQorKysgYi91dGlsL2xpYnNzbC5udW0KQEAgLTQ0OSwzICs0 NDksNCBAQCBTU0xfZ2V0X3JlY29yZF9wYWRkaW5nX2NhbGxiYWNrX2FyZyAgICAgNDQ5CTFf MV8xCUVYSVNUOjpGVU5DVElPTjoKIFNTTF9zZXRfYmxvY2tfcGFkZGluZyAgICAgICAgICAg ICAgICAgICA0NTAJMV8xXzEJRVhJU1Q6OkZVTkNUSU9OOgogU1NMX3NldF9yZWNvcmRfcGFk ZGluZ19jYWxsYmFja19hcmcgICAgIDQ1MQkxXzFfMQlFWElTVDo6RlVOQ1RJT046CiBTU0xf Q1RYX3NldF9yZWNvcmRfcGFkZGluZ19jYWxsYmFja19hcmcgNDUyCTFfMV8xCUVYSVNUOjpG VU5DVElPTjoKK1NTTF9DVFhfdXNlX3NlcnZlcmluZm9fZXggICAgICAgICAgICAgICA0NTMJ MV8xXzEJRVhJU1Q6OkZVTkNUSU9OOgo= --------------020000000909070005050907-- From nobody Wed May 3 13:21: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 E786F129C1B for ; Wed, 3 May 2017 13:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 yQRdvd3cBD1d for ; Wed, 3 May 2017 13:21:29 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E4F12DFE0 for ; Wed, 3 May 2017 13:19:08 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id h4so246636lfj.3 for ; Wed, 03 May 2017 13:19:08 -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=3umhUGnzd4S+Tkk3R7Bo29wFg9b6JNnklg6Ygv0ZOgE=; b=ZOnCjuoK1tBbRG0TOeA/G5mW70/mTK2Wwej+Qn5crRKo0ueVclHN1v1QVLwCHir46a p0zdKxwO0jaqf/WjGo05NRyT6O0sIaBrukRMNv2Sf603zlJy+uRYgrjcJKFYuoaGFsNP FuQCmNVoXJuVVLssPgghshK9KWwu9TxtUJQLuIRktSz7Er8XpHtdZ6nFl6fbGRZYEPn+ F6kCJEs1gRQyReLtDPQUxBeiMjivhMdNBhKY/+aSA8jCckkwxA18nQR/PNXs148HwBR+ rSkQMEgHmZgcsgZxSmVSmYwZMg7gJ7sNoFh58NR5PZfIJnxCZJoyb0kMwh6ZknTanAy5 yhnQ== 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=3umhUGnzd4S+Tkk3R7Bo29wFg9b6JNnklg6Ygv0ZOgE=; b=jCCpl9Z0MTdI72t7JEmVLaSsluEJhSJYXb9BXcwsFEBy7bVkfvfIL+dzcI02Ceawr7 jNsarn7PwVk+GvFfg+TOcbYbbl+pLs/XtJlRrxs+RYQa961bAAVXr1cPAFIWWXrjB8bN 7+3brD8yPODCWwIkwucPa4pZw0ZPqXhqBgatSgk3SPFAiwWP4WzYfQ2bDjztNDLozrcN paGkpbE+UF3wN+pGbCm1FND6ipo/re+aCKgZy3W42dpu0WvVxQ7jZmg2nw5bq5GfGFWw AvA7jALiWrz9CDGj8pUCdNhqA5gJ6l7xrvuaJqE24DGjyEqjf7gkjS2NocN/yRO9fuiX ejaw== X-Gm-Message-State: AN3rC/6LL70WqRsjfYjQofNTE1ZxbgCHkOBf7a/9lE6nnmMCIxFE4d+n 8JPEAoA/A22NlAvmxtzEnUpJiJO5Rw== X-Received: by 10.25.145.94 with SMTP id y30mr1844581lfj.14.1493842747190; Wed, 03 May 2017 13:19:07 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.212 with HTTP; Wed, 3 May 2017 13:19:06 -0700 (PDT) In-Reply-To: <590A2FA0.3070601@roumenpetrov.info> References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> From: Daniel Migault Date: Wed, 3 May 2017 16:19:06 -0400 X-Google-Sender-Auth: dul_5XdB62Hpzp-Mp9vFRy5z3p0 Message-ID: To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= Cc: curdle Content-Type: multipart/mixed; boundary=94eb2c1cd6204d625b054ea45e70 Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 03 May 2017 20:21:33 -0000 --94eb2c1cd6204d625b054ea45e70 Content-Type: multipart/alternative; boundary=94eb2c1cd6204d6255054ea45e6e --94eb2c1cd6204d6255054ea45e6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the file. Somehow I could not open the file. I am attaching the diff here. Please comment on the proposed changes. Yours, Daniel On Wed, May 3, 2017 at 3:29 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5= =D1=82=D1=80=D0=BE=D0=B2 wrote: > Hi > Daniel Migault wrote: > >> Hi, >> >> [snip] >> Romen please re-state your issues with the draft, clearly expose the >> issues >> as well as the alternate you would fine acceptable. >> > > I would like to propose an redaction over draft-ietf-curdle-rsa-sha2-03 > (see attached file draft-ietf-curdle-rsa-sha2-03+rpetrov.txt). > Attached file" draft-ietf-curdle-rsa-sha2-03+rpetrov.wdiff.html" shows > modifications as word-diff in html format : > - removed: red font, strikeout > - added : green font > > > I chose version 3 as this version is mostly fine with me except few > substitutions(rewording) to follow style of previous SSH related documen= ts > - [RFC4253], [RFC5656] and [RFC6187] (see modifications in chapter 2 Publ= ic > Key Algorithms). > No modification in structure of messages, formats and etc. > > > Using mostly word "Public Key Algorithm" will allow section(chapter) "4. > IANA Considerations" to be written in very simple manner. > The totally rewritten chapter adds references to [RFC4250] and [RFC4251]= . > > > Section "3. Discovery of signature algorithms supported by servers" in > not updated yet (depends from another discussion). > > > Regards, > Roumen Petrov > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c1cd6204d6255054ea45e6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the file. Somehow I could not open th= e file. I am attaching the diff here.=C2=A0 Please comment on the proposed = changes.
Yours,
Daniel

On Wed, May 3, 2017 at 3:29 PM, =D0=A0=D1= =83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 <pkixss= h@roumenpetrov.info> wrote:
Hi
Daniel Migault wrote:
Hi,

[snip]
Romen please re-state your issues with the draft, clearly expose the issues=
as well as the alternate you would fine acceptable.

I would like to propose an redaction over draft-ietf-curdle-rsa-sha2-03 (se= e attached file draft-ietf-curdle-rsa-sha2-03+rpetrov.txt).
Attached file" draft-ietf-curdle-rsa-sha2-03+rpetrov.wdiff.html&q= uot; shows modifications as word-diff in html format :
- removed: red font, strikeout
- added : green font


I chose version 3 as this version is mostly fine with me except few substit= utions(rewording)=C2=A0 to follow style of previous SSH related documents -= [RFC4253], [RFC5656] and [RFC6187] (see modifications in chapter 2 Public = Key Algorithms).
No modification in structure of messages, formats and etc.


Using mostly word "Public Key Algorithm" will allow section(chapt= er) "4. IANA Considerations" to be written in very simple manner.=
The totally rewritten chapter adds references to [RFC4250]=C2=A0 and [RFC42= 51] .


Section "3.=C2=A0 Discovery of signature algorithms supported by serve= rs" in not updated yet (depends from another discussion).


Regards,
Roumen Petrov


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

--94eb2c1cd6204d6255054ea45e6e-- --94eb2c1cd6204d625b054ea45e70 Content-Type: text/html; charset=UTF-8; name="Diff draft-ietf-curdle-rsa-sha2-03-rpetrov.txt - draft-ietf-curdle-rsa-sha2-03.txt.htm" Content-Disposition: attachment; filename="Diff draft-ietf-curdle-rsa-sha2-03-rpetrov.txt - draft-ietf-curdle-rsa-sha2-03.txt.htm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j29fbyal2 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPg0KPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQ1OiByZmNkaWZmICAtLT4NCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPg0KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAzLjIuMC00LWFtZDY0ICMx IFNNUCBEZWJpYW4gMy4yLjg0LTEgeDg2XzY0IEdOVS9MaW51eCAtLT4NCjwhLS0gVXNpbmcgYXdr OiAvdXNyL2Jpbi9nYXdrOiBHTlUgQXdrIDQuMC4xIC0tPg0KPCEtLSBVc2luZyBkaWZmOiAvdXNy L2Jpbi9kaWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjIgLS0+DQo8IS0tIFVzaW5nIHdkaWZm OiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4xLjIgLS0+DQo8aHRtbCB4bWxu cz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+PGhlYWQ+IA0KICA8bWV0YSBodHRwLWVx dWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+IA0K ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3Nz Ij4gDQogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWN1cmRsZS1yc2Etc2hhMi0wMy1ycGV0cm92 LnR4dCAtIGRyYWZ0LWlldGYtY3VyZGxlLXJzYS1zaGEyLTAzLnR4dDwvdGl0bGU+IA0KICA8c3R5 bGUgdHlwZT0idGV4dC9jc3MiPiANCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2lu LXJpZ2h0OiBhdXRvOyB9IA0KICAgIHRyICAgICAgeyB9IA0KICAgIHRkICAgICAgeyB3aGl0ZS1z cGFjZTogcHJlOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBm b250LXNpemU6IDAuODZlbTt9IA0KICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAN CiAgICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250 LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IA0KICAgIC5sZWZ0ICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IA0KICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjRkZGOyB9IA0KICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IA0K ICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQkZCOyB9IA0KICAgIC5yYmxvY2sgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IA0KICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjOEZGOyB9IA0KICAgIC5kZWxldGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IA0KICAg IC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IA0KICAgIC5jb250ICAgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjRUVFOyB9IA0KICAgIC5saW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj QUFBOyB9IA0KICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZG OyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0g DQogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gDQogICAgLmxlZnQgLmNv bnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IA0KICAgIC5yaWdodCAuY29udCB7IGJhY2tn cm91bmQtY29sb3I6ICNFRUU7IH0gDQogICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQtY29s b3I6ICM5RDk7IH0gDQogICAgLnJibG9jayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNERDY7 IH0gDQogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gDQogICAg LmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0gDQogICAgLnN0YXRzLCAu c3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IHBhZGRpbmc6IDJw eCAwOyB9IA0KICAgIHNwYW4uaGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNvbG9yOiAjYWFhO30gICAg YTpob3ZlciBzcGFuIHsgZGlzcGxheTogaW5saW5lOyB9ICAgIHRyLmNoYW5nZSB7IGJhY2tncm91 bmQtY29sb3I6IGdyYXk7IH0gDQogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiBibGFjayB9IA0KICA8L3N0eWxlPiANCiAgICAgPHNjcmlwdD4NCnZhciBjaHVu a19pbmRleCA9IDA7DQp2YXIgb2xkX2NodW5rID0gbnVsbDsNCg0KZnVuY3Rpb24gZm9ybWF0X2No dW5rKGluZGV4KSB7DQogICAgdmFyIHByZWZpeCA9ICJkaWZmIjsNCiAgICB2YXIgc3RyID0gaW5k ZXgudG9TdHJpbmcoKTsNCiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7DQog ICAgICAgIHByZWZpeCs9JzAnOw0KICAgIH0NCiAgICByZXR1cm4gcHJlZml4ICsgc3RyOw0KfQ0K DQpmdW5jdGlvbiBmaW5kX2NodW5rKG4pew0KICAgIHJldHVybiBkb2N1bWVudC5xdWVyeVNlbGVj dG9yKCd0cltpZCQ9IicgKyBuICsgJyJdJyk7DQp9DQoNCmZ1bmN0aW9uIGNoYW5nZV9jaHVuayhv ZmZzZXQpIHsNCiAgICB2YXIgaW5kZXggPSBjaHVua19pbmRleCArIG9mZnNldDsNCiAgICB2YXIg bmV3X3N0cjsNCiAgICB2YXIgbmV3X2NodW5rOw0KDQogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVu ayhpbmRleCk7DQogICAgbmV3X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsNCiAgICBpZiAo IW5ld19jaHVuaykgew0KICAgICAgICByZXR1cm47DQogICAgfQ0KICAgIGlmIChvbGRfY2h1bmsp IHsNCiAgICAgICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiIjsNCiAgICB9DQogICAgb2xk X2NodW5rID0gbmV3X2NodW5rOw0KICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBz b2xpZCByZWQiOw0KICAgIHdpbmRvdy5sb2NhdGlvbi5oYXNoID0gIiMiICsgbmV3X3N0cjsNCiAg ICB3aW5kb3cuc2Nyb2xsQnkoMCwtMTAwKTsNCiAgICBjaHVua19pbmRleCA9IGluZGV4Ow0KfQ0K DQpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7DQogICAgc3dpdGNoIChlLmtleUNv ZGUpIHsNCiAgICBjYXNlIDc4Og0KICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7DQogICAgICAgIGJy ZWFrOw0KICAgIGNhc2UgODA6DQogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7DQogICAgICAgIGJy ZWFrOw0KICAgIH0NCn07DQogICA8L3NjcmlwdD4gDQo8c2NyaXB0PihmdW5jdGlvbiBuKCl7IWZ1 bmN0aW9uKCl7ZnVuY3Rpb24gZShlLHQsbil7dD10fHx7fTt2YXIgaT1lLm93bmVyRG9jdW1lbnR8 fGUsYT1pLmNyZWF0ZUV2ZW50P2kuY3JlYXRlRXZlbnQoIkN1c3RvbUV2ZW50Iik6aS5jcmVhdGVF dmVudE9iamVjdCgpO2EuaW5pdEN1c3RvbUV2ZW50JiZhLmluaXRDdXN0b21FdmVudCh0LnR5cGUs ISF0LmJ1YmJsZXMsISF0LmNhbmNlbGFibGUsdC5kZXRhaWwpO2Zvcih2YXIgciBpbiB0KWFbcl09 dFtyXTtyZXR1cm4gc2V0VGltZW91dChmdW5jdGlvbigpe3RyeXtlLmRpc3BhdGNoRXZlbnQ/ZS5k aXNwYXRjaEV2ZW50KGEpOmUuZmlyZUV2ZW50KCJvbiIrdC50eXBlLGkuY3JlYXRlRXZlbnRPYmpl Y3QoKSl9Y2F0Y2gobil7dmFyIHI9ZVsibGlzdGVuIit0LnR5cGVdO2lmKHIpZm9yKHZhciBsPTA7 bDxyLmxlbmd0aDsrK2wpdHJ5e3JbbF0uY2FsbChlLGEpfWNhdGNoKGUpe319bigpfSwwKSx0aGlz fWZ1bmN0aW9uIHQoZSx0LG4pe2Z1bmN0aW9uIGkoZSx0KXt0cnl7dmFyIG49ZS5vd25lckRvY3Vt ZW50O2lmKG4uY3JlYXRlRXZlbnRPYmplY3Qpe3ZhciBpPW4uY3JlYXRlRXZlbnRPYmplY3QoKTtl LmZpcmVFdmVudCgib24iK3QsaSl9ZWxzZSBpPW4uY3JlYXRlRXZlbnQoIkhUTUxFdmVudHMiKSxp LmluaXRFdmVudCh0LCEwLCEwKSxlLmRpc3BhdGNoRXZlbnQoaSl9Y2F0Y2goZSl7fX12YXIgYT0h MCxyPWUuY2xhc3NOYW1lJiZlLmNsYXNzTmFtZS5pbmRleE9mKCJmYW5jaWZpZWQiKSE9LTE7aWYo d2luZG93LmpRdWVyeSl7dmFyIGw9d2luZG93LmpRdWVyeShlKTt0cnl7aWYobC5zZWxlY3RCb3hJ dClsLnNlbGVjdEJveEl0KCJzZWxlY3RPcHRpb24iLGwudmFsKCkpO2Vsc2UgaWYobC5kYXRhKCJj aG9zZW4iKXx8bC5jaG9zZW4pbC50cmlnZ2VyKCJjaG9zZW46dXBkYXRlZCIpLnRyaWdnZXIoImxp c3p0OnVwZGF0ZWQiKTtlbHNlIGlmKGwuZGF0YSgiY2hvb3NlckVsZW1lbnQiKSlsLnRyaWdnZXIo ImNoYW5nZSIpO2Vsc2UgaWYobC5mYW5jeVNlbGVjdClsLmdldCgiZmFuY3lTZWxlY3QiKS5zZWxl Y3QoInZhbHVlIixsLnZhbCgpKTtlbHNlIGlmKGwuc2VsZWN0Qm94KWwuc2VsZWN0Qm94KCJ2YWx1 ZSIsbC52YWwoKSk7ZWxzZSBpZihsLnNlbGVjdHJpYylsLnNlbGVjdHJpYygicmVmcmVzaCIpO2Vs c2UgaWYobC5jb3JlVUlTZWxlY3Qpe3ZhciBzPWwuZGF0YSgiY29yZVVJU2VsZWN0Iik7cy5pc1Nl bGVjdFNob3c9ITAscy5jaGFuZ2VEcm9wZG93bkRhdGEoKSxzLmlzU2VsZWN0U2hvdz0hMX1lbHNl IGlmKGwuZGF0YSgibXlKU1B1bGxkb3duT2JqZWN0Iikpe3ZhciBvPWwuZGF0YSgibXlKU1B1bGxk b3duT2JqZWN0Iik7by5zZXRUb1ZhbHVlKGwudmFsKCkpfWVsc2UgaWYobC5mYW5jeWZpZWxkcyls LnNldFZhbChsLnZhbCgpKTtlbHNlIGlmKGwuZGF0YSgic2VsZWN0MiIpKTtlbHNlIGlmKGwuZGF0 YSgic2VsZWN0aXplIikpYT0hMSxsLmRhdGEoInNlbGVjdGl6ZSIpLnNldFZhbHVlKGwudmFsKCkp O2Vsc2UgaWYobC5oYXNDbGFzcygiZmFuY2lmaWVkIikpbC50cmlnZ2VyKCJ1cGRhdGUiKTtlbHNl IGlmKGwuc2VsZWN0bWVudSl7dmFyIGM9bC52YWwoKTt0cnl7bC5zZWxlY3RtZW51KCJ2YWx1ZSIs bFswXS5vcHRpb25zWzBdLnZhbHVlKX1jYXRjaChlKXt9bC5zZWxlY3RtZW51KCJ2YWx1ZSIsYyl9 bC50cmlnZ2VyKCJjaGFuZ2UiKX1jYXRjaChlKXt9fWEmJihyJiZpKGUsInVwZGF0ZSIpLGkoZSwi Y2hhbmdlIiksaShlLCJibHVyIikpLG4oKX1mdW5jdGlvbiBuKHQsbixpLGEpe3ZhciByPXQudmFs dWU7ZSh0LHt0eXBlOiJrZXlkb3duIixrZXlDb2RlOm4sd2hpY2g6bixjaGFyQ29kZTpuLGJ1YmJs ZXM6ITB9LGZ1bmN0aW9uKCl7ZSh0LHt0eXBlOiJrZXlwcmVzcyIsa2V5Q29kZTpuLHdoaWNoOm4s Y2hhckNvZGU6bixidWJibGVzOiEwfSxmdW5jdGlvbigpe3NldFRpbWVvdXQoZnVuY3Rpb24oKXt2 YXIgbD10LnZhbHVlO3I9PWwmJih0LnZhbHVlPWkpLGUodCx7dHlwZToiaW5wdXQiLGtleUNvZGU6 bix3aGljaDpuLGNoYXJDb2RlOm4sYnViYmxlczohMH0sZnVuY3Rpb24oKXtlKHQse3R5cGU6Imtl eXVwIixrZXlDb2RlOm4sd2hpY2g6bixjaGFyQ29kZTpuLGJ1YmJsZXM6ITB9LGZ1bmN0aW9uKCl7 YSgpfSl9KX0sMSl9KX0pfWZ1bmN0aW9uIGkoZSx0LGEscil7aWYoIXR8fCIiPT10KXJldHVybiB2 b2lkIHIoKTt2YXIgbD10LmNoYXJDb2RlQXQoMCk7YSs9dC5jaGFyQXQoMCksbihlLGwsYSxmdW5j dGlvbigpe2koZSx0LnN1YnN0cmluZygxKSxhLHIpfSl9ZnVuY3Rpb24gYSh0LG4saSl7aWYod2lu ZG93LmFiaW5lVHJpZ2dlckNoYW5nZUluUHJvZ3Jlc3MpcmV0dXJuIHZvaWQgc2V0VGltZW91dChm dW5jdGlvbigpe2EodCxuLGkpfSwxMDApO3dpbmRvdy5hYmluZVRyaWdnZXJDaGFuZ2VJblByb2dy ZXNzPSEwO3RyeXtpZih3aW5kb3cualF1ZXJ5KXt2YXIgcj13aW5kb3cualF1ZXJ5KHQpOyhyLmRh dGEoInJhd01hc2tGbiIpfHxyLm1hc2t8fHIuQ2FyZFBob25lRm9ybWF0dGluZykmJnIuZm9jdXMo KS52YWwobikudHJpZ2dlcigiaW5wdXQiKS50cmlnZ2VyKCJwYXN0ZSIpfX1jYXRjaChlKXt9ZSh0 LHt0eXBlOiJjaGFuZ2UifSxmdW5jdGlvbigpe2UodCx7dHlwZToiYmx1ciJ9LGZ1bmN0aW9uKCl7 dHJ5e3ZhciBlPW5ldyBFdmVudCgiaW5wdXQiLHtidWJibGVzOiEwLGNhbmNlbGFibGU6ITB9KTt0 LmRpc3BhdGNoRXZlbnQoZSl9Y2F0Y2goZSl7fXdpbmRvdy5hYmluZVRyaWdnZXJDaGFuZ2VJblBy b2dyZXNzPSExLGkoKX0pfSl9ZnVuY3Rpb24gcih0LG4scil7ZSh0LHt0eXBlOiJmb2N1cyJ9LGZ1 bmN0aW9uKCl7ZSh0LHt0eXBlOiJjbGljayJ9LGZ1bmN0aW9uKCl7aSh0LG4sIiIsZnVuY3Rpb24o KXthKHQsbixmdW5jdGlvbigpe2UoZG9jdW1lbnQse3R5cGU6ImFiaW5lRmlsbGVkIn0sZnVuY3Rp b24oKXtyKCl9KX0pfSl9KX0pfWZ1bmN0aW9uIGwobixpLGEscil7dmFyIGw9L1tcc10rL2cscz0o aXx8IiIpLnRvTG93ZXJDYXNlKCkucmVwbGFjZShsLCIiKSxvPWZ1bmN0aW9uKCl7ZShkb2N1bWVu dCx7dHlwZToiYWJpbmVGaWxsZWQifSxmdW5jdGlvbigpe3IoKX0pfSxjPSExLGQ9ITEsdT1uLmdl dEVsZW1lbnRzQnlUYWdOYW1lKCJvcHRpb24iKTtpZih1JiZ1Lmxlbmd0aD4wKXtmb3IodmFyIG09 LTEsZj0wO2Y8dS5sZW5ndGg7ZisrKXt2YXIgaD0odVtmXS50ZXh0fHwiIikudG9Mb3dlckNhc2Uo KS5yZXBsYWNlKGwsIiIpLHA9KHVbZl0uZ2V0QXR0cmlidXRlKCJ2YWx1ZSIpfHwiIikudG9Mb3dl ckNhc2UoKS5yZXBsYWNlKGwsIiIpO2lmKHA9PXN8fGg9PXMpe3VbZl0uc2VsZWN0ZWR8fChjPSEw LHVbZl0uc2VsZWN0ZWQ9ITApLGQ9ITA7YnJlYWt9bT09LTEmJmguaW5kZXhPZihzKSE9LTEmJiht PWYpfWR8fG09PS0xfHxhfHx1W21dLnNlbGVjdGVkfHwoYz0hMCx1W21dLnNlbGVjdGVkPSEwLGQ9 ITApfW4uc2V0QXR0cmlidXRlKCJhYmluZUZpbGxSZXNwb25zZSIsZCksYz90KG4saSxvKTpvKCl9 ZnVuY3Rpb24gcygpe3ZhciBlPWRvY3VtZW50LmdldEVsZW1lbnRzQnlDbGFzc05hbWUoImFiaW5l RmlsbFRhcmdldCIpO2lmKGUubGVuZ3RoPjApcmV0dXJuIGVbMF07Zm9yKHZhciB0PTA7dDxmcmFt ZXMubGVuZ3RoO3QrKyl0cnl7dmFyIGU9ZnJhbWVzW3RdLmRvY3VtZW50LmdldEVsZW1lbnRzQnlD bGFzc05hbWUoImFiaW5lRmlsbFRhcmdldCIpO2lmKGUubGVuZ3RoPjApcmV0dXJuIGVbMF19Y2F0 Y2goZSl7fXJldHVybiBudWxsfWZ1bmN0aW9uIG8oKXt2YXIgbj1kb2N1bWVudC5jcmVhdGVFbGVt ZW50KCJkaXYiKTtuLmlkPSJhYmluZUZpbGxFbGVtZW50IiwidW5kZWZpbmVkIiE9dHlwZW9mIHBh eXBhbCYmbi5zZXRBdHRyaWJ1dGUoImRhdGEtcGF5cGFsIiwiMSIpLCJ1bmRlZmluZWQiIT10eXBl b2YgT2ZmQW1hem9uUGF5bWVudHMmJm4uc2V0QXR0cmlidXRlKCJkYXRhLWFtYXpvbiIsIjEiKSwi dW5kZWZpbmVkIiE9dHlwZW9mIE1hc3RlclBhc3MmJm4uc2V0QXR0cmlidXRlKCJkYXRhLW1hc3Rl cnBhc3MiLCIxIiksZG9jdW1lbnQuZG9jdW1lbnRFbGVtZW50LmFwcGVuZENoaWxkKG4pLG4uYWRk RXZlbnRMaXN0ZW5lcigiZmlsbCIsZnVuY3Rpb24oKXt2YXIgdD1zKCk7aWYodCl7dmFyIGk9bi5n ZXRBdHRyaWJ1dGUoInZhbHVlIik7cih0LGksZnVuY3Rpb24oKXt9KX1lbHNlIGUoZG9jdW1lbnQs e3R5cGU6ImFiaW5lRmlsbGVkIn0sZnVuY3Rpb24oKXt9KX0sITEpLG4uYWRkRXZlbnRMaXN0ZW5l cigiZmlsbFNlbGVjdCIsZnVuY3Rpb24oKXt2YXIgdD1zKCk7aWYodCl7dmFyIGk9bi5nZXRBdHRy aWJ1dGUoInZhbHVlIiksYT0hIW4uZ2V0QXR0cmlidXRlKCJza2lwUGFydGlhbCIpO2wodCxpLGEs ZnVuY3Rpb24oKXt9KX1lbHNlIGUoZG9jdW1lbnQse3R5cGU6ImFiaW5lRmlsbGVkIn0sZnVuY3Rp b24oKXt9KX0pLG4uYWRkRXZlbnRMaXN0ZW5lcigidHJpZ2dlckNoYW5nZSIsZnVuY3Rpb24oKXt2 YXIgZT1zKCksaT1uLmdldEF0dHJpYnV0ZSgidmFsdWUiKTtlJiYoZS5ub2RlTmFtZS5tYXRjaCgv c2VsZWN0L2kpP3QoZSxpLGZ1bmN0aW9uKCl7fSk6YShlLGksZnVuY3Rpb24oKXt9KSl9KX1vKCl9 KCl9KSgpPC9zY3JpcHQ+PC9oZWFkPiANCjxib2R5PiANCiAgPHRhYmxlIGNlbGxzcGFjaW5nPSIw IiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIj4gDQogIDx0Ym9keT48dHIgaWQ9InBhcnQtMSIg Ymdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jdXJkbGUtcnNhLXNoYTItMDMtcnBldHJvdi50 eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY3VyZGxl LXJzYS1zaGEyLTAzLXJwZXRyb3YudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1j dXJkbGUtcnNhLXNoYTItMDMtcnBldHJvdi50eHQ8L2E+Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRo PiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWN1 cmRsZS1yc2Etc2hhMi0wMy50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLWN1cmRs ZS1yc2Etc2hhMi0wMy50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1jdXJkbGUtcnNhLXNoYTItMDMudHh0IiBzdHlsZT0i Y29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mZ3Q7PC9hPjwvdGg+PHRoPjwvdGg+ PC90cj4gDQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+DQogICAgICA8dHIgaWQ9InBhcnQtMSIgY2xhc3M9ImNoYW5nZSI+PHRkPjwv dGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0 LTEiPjxlbT4gcGFnZSAyLCBsaW5lIDI5PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2Vt PjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGEgaHJlZj0iI3BhcnQtMSI+PGVtPiBwYWdlIDIsIGxpbmUgMjk8c3BhbiBjbGFzcz0iaGlk ZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEuMS4gIFJlcXVpcmVt ZW50cyBUZXJtaW5vbG9neTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuMS4gIFJl cXVpcmVtZW50cyBUZXJtaW5vbG9neTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgVGhlIGtleSB3 b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtS RkMyMTE5XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuICBQdWJsaWMgS2V5IEFsZ29yaXRobXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLiAgUHVibGljIEtleSBBbGdvcml0aG1zPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBUaGlzIG1lbW8gYWRvcHRzIHRoZSBzdHlsZSBh bmQgY29udmVudGlvbnMgb2YgW1JGQzQyNTNdIGluIHNwZWNpZnlpbmc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gIFRoaXMgbWVtbyBhZG9wdHMgdGhlIHN0eWxlIGFuZCBjb252ZW50 aW9ucyBvZiBbUkZDNDI1M10gaW4gc3BlY2lmeWluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4NCiAgICAgIDx0ciBpZD0iZGlmZjAwMDEiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgaG93IHVzZSBv ZiBhIDxzcGFuIGNsYXNzPSJkZWxldGUiPnB1YmxpYyBrZXk8L3NwYW4+IGFsZ29yaXRobSBpcyBp bmRpY2F0ZWQgaW4gU1NILjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIGhvdyB1 c2Ugb2YgYSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaWduYXR1cmU8L3NwYW4+IGFsZ29yaXRobSBp cyBpbmRpY2F0ZWQgaW4gU1NILjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4NCiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgVGhlIGZvbGxvd2luZyBu ZXcgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+cHVibGljIGtleTwvc3Bhbj4gYWxnb3JpdGhtcyBhcmUg ZGVmaW5lZDo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICBUaGUgZm9sbG93aW5n IG5ldyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaWduYXR1cmU8L3NwYW4+IGFsZ29yaXRobXMgYXJl IGRlZmluZWQ6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHJzYS1zaGEy LTI1NiAgICBSRUNPTU1FTkRFRCAgICBzaWduICAgIFJhdyBSU0Ega2V5PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgIHJzYS1zaGEyLTI1NiAgICBSRUNPTU1FTkRFRCAgICBzaWdu ICAgIFJhdyBSU0Ega2V5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHJzYS1zaGEy LTUxMiAgICBPUFRJT05BTCAgICAgICBzaWduICAgIFJhdyBSU0Ega2V5PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgIHJzYS1zaGEyLTUxMiAgICBPUFRJT05BTCAgICAgICBzaWdu ICAgIFJhdyBSU0Ega2V5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0K ICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICBUaGVzZSBhbGdvcml0aG1zIGFy ZSBzdWl0YWJsZSBmb3IgdXNlIGJvdGggaW4gdGhlIFNTSCB0cmFuc3BvcnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICBUaGVzZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaWduYXR1 cmUgPC9zcGFuPmFsZ29yaXRobXMgYXJlIHN1aXRhYmxlIGZvciB1c2UgYm90aCBpbiB0aGUgU1NI IHRyYW5zcG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgbGF5ZXIgW1JGQzQyNTNd IGZvciBzZXJ2ZXIgYXV0aGVudGljYXRpb24sIGFuZCBpbiB0aGUgYXV0aGVudGljYXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGxheWVyIFtSRkM0MjUzXSBmb3Igc2VydmVy IGF1dGhlbnRpY2F0aW9uLCBhbmQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICBsYXllciBbUkZDNDI1Ml0gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlv bi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGxheWVyIFtSRkM0MjUyXSBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4NCiAgICAgIDx0ciBpZD0iZGlmZjAwMDQiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPjIuMS4gIFB1YmxpYyBLZXkgRm9ybWF0PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICBTaW5jZSBSU0Ega2V5cyBhcmUgbm90IGRlcGVuZGVudCBvbiB0aGUgY2hv aWNlIG9mIGhhc2ggZnVuY3Rpb24sIGJvdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gIFNpbmNlIFJTQSBrZXlzIGFyZSBub3QgZGVwZW5kZW50IG9uIHRoZSBjaG9pY2Ugb2YgaGFz aCBmdW5jdGlvbiwgYm90aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgbmV3IGFsZ29y aXRobXMgcmV1c2UgdGhlIHB1YmxpYyBrZXkgZm9ybWF0IG9mIHRoZSBleGlzdGluZyAic3NoLXJz YSI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIG5ldyBhbGdvcml0aG1zIHJldXNl IHRoZSBwdWJsaWMga2V5IGZvcm1hdCBvZiB0aGUgZXhpc3RpbmcgInNzaC1yc2EiPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBhbGdvcml0aG0gYXMgZGVmaW5lZCBpbiBbUkZDNDI1M106 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBhbGdvcml0aG0gYXMgZGVmaW5lZCBp biBbUkZDNDI1M106PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHN0cmlu ZyAgICAic3NoLXJzYSI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgc3RyaW5n ICAgICJzc2gtcnNhIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICBtcGludCAgICAg ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICBtcGludCAgICAgZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICBtcGludCAgICAgbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICBtcGludCAgICAgbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgQWxsIGFzcGVjdHMgb2YgdGhlICJzc2gtcnNhIiBmb3JtYXQgYXJlIGtlcHQsIGlu Y2x1ZGluZyB0aGUgZW5jb2RlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgQWxs IGFzcGVjdHMgb2YgdGhlICJzc2gtcnNhIiBmb3JtYXQgYXJlIGtlcHQsIGluY2x1ZGluZyB0aGUg ZW5jb2RlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgc3RyaW5nICJzc2gtcnNhIiwg aW4gb3JkZXIgdG8gYWxsb3cgdXNlcnMnIGV4aXN0aW5nIFJTQSBrZXlzIHRvIGJlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBzdHJpbmcgInNzaC1yc2EiLCBpbiBvcmRlciB0byBh bGxvdyB1c2VycycgZXhpc3RpbmcgUlNBIGtleXMgdG8gYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gIHVzZWQgd2l0aCB0aGUgbmV3IHNpZ25hdHVyZSBmb3JtYXRzLCB3aXRob3V0IHJl cXVpcmluZyByZS1lbmNvZGluZyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIHVz ZWQgd2l0aCB0aGUgbmV3IHNpZ25hdHVyZSBmb3JtYXRzLCB3aXRob3V0IHJlcXVpcmluZyByZS1l bmNvZGluZyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIG9yIGFmZmVjdGluZyBhbHJl YWR5IHRydXN0ZWQga2V5IGZpbmdlcnByaW50cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gIG9yIGFmZmVjdGluZyBhbHJlYWR5IHRydXN0ZWQga2V5IGZpbmdlcnByaW50cy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgaWQ9ImRpZmYw MDA1Ij48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4yLjIuICBTaWduYXR1cmUgRW5j b2Rpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFNpZ25pbmcgYW5k IHZlcmlmeWluZyB1c2luZyB0aGVzZSBhbGdvcml0aG1zIGlzIHBlcmZvcm1lZCBhY2NvcmRpbmcg dG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFNpZ25pbmcgYW5kIHZlcmlmeWlu ZyB1c2luZyB0aGVzZSBhbGdvcml0aG1zIGlzIHBlcmZvcm1lZCBhY2NvcmRpbmcgdG88L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHRoZSBSU0FTU0EtUEtDUzEtdjFfNSBzY2hlbWUgaW4g W1JGQzM0NDddIHVzaW5nIFNIQS0yIFtGSVBTLTE4MC00XSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgdGhlIFJTQVNTQS1QS0NTMS12MV81IHNjaGVtZSBpbiBbUkZDMzQ0N10g dXNpbmcgU0hBLTIgW0ZJUFMtMTgwLTRdIGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICBoYXNoOyBNR0YxIGFzIG1hc2sgZnVuY3Rpb247IGFuZCBzYWx0IGxlbmd0aCBlcXVhbCB0byBo YXNoIHNpemUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBoYXNoOyBNR0YxIGFz IG1hc2sgZnVuY3Rpb247IGFuZCBzYWx0IGxlbmd0aCBlcXVhbCB0byBoYXNoIHNpemUuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBGb3IgdGhlIGFsZ29yaXRobSAicnNhLXNo YTItMjU2IiwgdGhlIGhhc2ggdXNlZCBpcyBTSEEtMiAyNTYuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICBGb3IgdGhlIGFsZ29yaXRobSAicnNhLXNoYTItMjU2IiwgdGhlIGhhc2gg dXNlZCBpcyBTSEEtMiAyNTYuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBGb3IgdGhl IGFsZ29yaXRobSAicnNhLXNoYTItNTEyIiwgdGhlIGhhc2ggdXNlZCBpcyBTSEEtMiA1MTIuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBGb3IgdGhlIGFsZ29yaXRobSAicnNhLXNo YTItNTEyIiwgdGhlIGhhc2ggdXNlZCBpcyBTSEEtMiA1MTIuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICBUaGUgcmVzdWx0aW5nIHNpZ25hdHVyZSBpcyBlbmNvZGVkIGFzIGZv bGxvd3M6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBUaGUgcmVzdWx0aW5nIHNp Z25hdHVyZSBpcyBlbmNvZGVkIGFzIGZvbGxvd3M6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgIHN0cmluZyAgICAicnNhLXNoYTItMjU2IiAvICJyc2Etc2hhMi01MTIiPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHN0cmluZyAgICAicnNhLXNoYTItMjU2 IiAvICJyc2Etc2hhMi01MTIiPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHN0cmlu ZyAgICByc2Ffc2lnbmF0dXJlX2Jsb2I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgc3RyaW5nICAgIHJzYV9zaWduYXR1cmVfYmxvYjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgVGhlIHZhbHVlIGZvciAncnNhX3NpZ25hdHVyZV9ibG9iJyBpcyBlbmNvZGVk IGFzIGEgc3RyaW5nIGNvbnRhaW5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g IFRoZSB2YWx1ZSBmb3IgJ3JzYV9zaWduYXR1cmVfYmxvYicgaXMgZW5jb2RlZCBhcyBhIHN0cmlu ZyBjb250YWluaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBTIC0gYW4gb2N0ZXQg c3RyaW5nIHdoaWNoIGlzIHRoZSBvdXRwdXQgb2YgUlNBU1NBLVBLQ1MxLXYxXzUsIG9mPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBTIC0gYW4gb2N0ZXQgc3RyaW5nIHdoaWNoIGlz IHRoZSBvdXRwdXQgb2YgUlNBU1NBLVBLQ1MxLXYxXzUsIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICBsZW5ndGggZXF1YWwgdG8gdGhlIGxlbmd0aCBpbiBvY3RldHMgb2YgdGhlIFJT QSBtb2R1bHVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgbGVuZ3RoIGVxdWFs IHRvIHRoZSBsZW5ndGggaW4gb2N0ZXRzIG9mIHRoZSBSU0EgbW9kdWx1cy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4yLjxzcGFuIGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+LiAgVXNlIGZvciBzZXJ2ZXIg YXV0aGVudGljYXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+Mi48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4xPC9zcGFuPi4gIFVzZSBmb3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBUbyBleHByZXNzIHN1cHBvcnQgYW5k IHByZWZlcmVuY2UgZm9yIG9uZSBvciBib3RoIG9mIHRoZXNlIGFsZ29yaXRobXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFRvIGV4cHJlc3Mgc3VwcG9ydCBhbmQgcHJlZmVyZW5j ZSBmb3Igb25lIG9yIGJvdGggb2YgdGhlc2UgYWxnb3JpdGhtczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgdGhlIFNTSCBjbGllbnQgb3Ig c2VydmVyIGluY2x1ZGVzIG9uZSBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg Zm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgdGhlIFNTSCBjbGllbnQgb3Igc2VydmVyIGluY2x1 ZGVzIG9uZSBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgYm90aCBhbGdvcml0aG0g bmFtZXMsICJyc2Etc2hhMi0yNTYiIGFuZC9vciAicnNhLXNoYTItNTEyIiwgaW4gdGhlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBib3RoIGFsZ29yaXRobSBuYW1lcywgInJzYS1z aGEyLTI1NiIgYW5kL29yICJyc2Etc2hhMi01MTIiLCBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gIG5hbWUtbGlzdCBmaWVsZCAic2VydmVyX2hvc3Rfa2V5X2FsZ29yaXRobXMi IGluIHRoZSBTU0hfTVNHX0tFWElOSVQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g IG5hbWUtbGlzdCBmaWVsZCAic2VydmVyX2hvc3Rfa2V5X2FsZ29yaXRobXMiIGluIHRoZSBTU0hf TVNHX0tFWElOSVQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHBhY2tldCBbUkZDNDI1 M10uIElmIG9uZSBvZiB0aGUgdHdvIGhvc3Qga2V5IGFsZ29yaXRobXMgaXMgbmVnb3RpYXRlZCw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIHBhY2tldCBbUkZDNDI1M10uIElmIG9u ZSBvZiB0aGUgdHdvIGhvc3Qga2V5IGFsZ29yaXRobXMgaXMgbmVnb3RpYXRlZCw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gInNzaC1yc2EiIHB1Ymxp YyBrZXkgYXMgcGFydCBvZiB0aGUgbmVnb3RpYXRlZCBrZXk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gInNzaC1yc2EiIHB1YmxpYyBrZXkgYXMg cGFydCBvZiB0aGUgbmVnb3RpYXRlZCBrZXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g IGV4Y2hhbmdlIG1ldGhvZCAoZS5nLiBpbiBTU0hfTVNHX0tFWERIX1JFUExZKSwgYW5kIGVuY29k ZXMgYSBzaWduYXR1cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGV4Y2hhbmdl IG1ldGhvZCAoZS5nLiBpbiBTU0hfTVNHX0tFWERIX1JFUExZKSwgYW5kIGVuY29kZXMgYSBzaWdu YXR1cmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHdpdGggdGhlIGFwcHJvcHJpYXRl IHNpZ25hdHVyZSBhbGdvcml0aG0gbmFtZSAtIGVpdGhlciAicnNhLXNoYTItMjU2Iiw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIHdpdGggdGhlIGFwcHJvcHJpYXRlIHNpZ25hdHVy ZSBhbGdvcml0aG0gbmFtZSAtIGVpdGhlciAicnNhLXNoYTItMjU2Iiw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gIG9yICJyc2Etc2hhMi01MTIiLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgb3IgInJzYS1zaGEyLTUxMiIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyIGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+Mi48c3Bh biBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPi4gIFVzZSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjIuPHNwYW4gY2xhc3M9Imluc2VydCI+ Mjwvc3Bhbj4uICBVc2UgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgVG8gdXNlIHRoaXMgYWxnb3JpdGhtIGZvciBjbGllbnQgYXV0 aGVudGljYXRpb24sIHRoZSBTU0ggY2xpZW50IHNlbmRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICBUbyB1c2UgdGhpcyBhbGdvcml0aG0gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlv biwgdGhlIFNTSCBjbGllbnQgc2VuZHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIGFu IFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVCBtZXNzYWdlIFtSRkM0MjUyXSBlbmNvZGluZyB0aGUg InB1YmxpY2tleSI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIGFuIFNTSF9NU0df VVNFUkFVVEhfUkVRVUVTVCBtZXNzYWdlIFtSRkM0MjUyXSBlbmNvZGluZyB0aGUgInB1YmxpY2tl eSI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIG1ldGhvZCwgYW5kIGVuY29kaW5nIHRo ZSBzdHJpbmcgZmllbGQgInB1YmxpYyBrZXkgYWxnb3JpdGhtIG5hbWUiIHdpdGg8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIG1ldGhvZCwgYW5kIGVuY29kaW5nIHRoZSBzdHJpbmcg ZmllbGQgInB1YmxpYyBrZXkgYWxnb3JpdGhtIG5hbWUiIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gIHRoZSB2YWx1ZSAicnNhLXNoYTItMjU2IiBvciAicnNhLXNoYTItNTEyIi4g VGhlICJwdWJsaWMga2V5IGJsb2IiPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICB0 aGUgdmFsdWUgInJzYS1zaGEyLTI1NiIgb3IgInJzYS1zaGEyLTUxMiIuIFRoZSAicHVibGljIGtl eSBibG9iIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBpZD0i ZGlmZjAwMDgiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgZmllbGQgZW5jb2RlcyB0aGUgUlNBIHB1YmxpYyBrZXkg dXNpbmcgdGhlICJzc2gtcnNhIiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mb3JtYXQgaWRlbnRpZmll cjwvc3Bhbj4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgZmllbGQgZW5jb2Rl cyB0aGUgUlNBIHB1YmxpYyBrZXkgdXNpbmcgdGhlICJzc2gtcnNhIiA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5hbGdvcml0aG0gbmFtZTwvc3Bhbj4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICBUaGUgc2lnbmF0dXJlIGZpZWxkLCBpZiBwcmVzZW50LCBlbmNvZGVzIGEgc2lnbmF0dXJlIHVz aW5nIGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBUaGUgc2lnbmF0dXJlIGZp ZWxkLCBpZiBwcmVzZW50LCBlbmNvZGVzIGEgc2lnbmF0dXJlIHVzaW5nIGFuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGlkPSJkaWZmMDAwOSI+PHRkPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zaWduYXR1cmUgZm9ybWF0IGlkZW50aWZpZXIgdGhh dCBNVVNUIG1hdGNoIHRoZSBhbGdvcml0aG0gbmFtZSBpbjwvc3Bhbj4gU1NIIGF1dGhlbnRpY2F0 aW9uIHJlcXVlc3QgLSBlaXRoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbGdvcml0aG0gbmFtZSB0aGF0IE1VU1QgbWF0Y2ggdGhlPC9z cGFuPiBTU0ggYXV0aGVudGljYXRpb24gcmVxdWVzdCAtIGVpdGhlcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgInJzYS1zaGEyLTI1NiIsIG9yICJyc2Etc2hhMi01MTIiLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgInJzYS1zaGEyLTI1NiIsIG9yICJyc2Etc2hhMi01 MTIiLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBp ZD0iZGlmZjAwMTAiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgRm9yIGV4YW1wbGUsIGFuIFNTSCAicHVibGlja2V5 IiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zaWduZWQ8L3NwYW4+IGF1dGhlbnRpY2F0aW9uIHJlcXVl c3QgdXNpbmcgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICBGb3IgZXhhbXBs ZSwgYW4gU1NIICJwdWJsaWNrZXkiIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QgdXNpbmcgYW48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgInJzYS1zaGEyLTUxMiIgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+YWxnb3JpdGhtPC9zcGFuPiB3b3VsZCBiZSBwcm9wZXJseSBlbmNvZGVkIGFzIGZv bGxvd3M6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgInJzYS1zaGEyLTUxMiIg PHNwYW4gY2xhc3M9Imluc2VydCI+c2lnbmF0dXJlPC9zcGFuPiB3b3VsZCBiZSBwcm9wZXJseSBl bmNvZGVkIGFzIGZvbGxvd3M6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg IGJ5dGUgICAgICBTU0hfTVNHX1VTRVJBVVRIX1JFUVVFU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgYnl0ZSAgICAgIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICBzdHJpbmcgICAgdXNlciBuYW1lPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHN0cmluZyAgICB1c2VyIG5hbWU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgc3RyaW5nICAgIHNlcnZpY2UgbmFtZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICBzdHJpbmcgICAgc2VydmljZSBuYW1lPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHN0cmluZyAgICAicHVibGlja2V5IjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICBzdHJpbmcgICAgInB1YmxpY2tleSI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgYm9vbGVhbiAgIFRSVUU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgYm9vbGVhbiAgIFRSVUU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgc3RyaW5nICAgICJyc2Etc2hhMi01MTIiPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgIHN0cmluZyAgICAicnNhLXNoYTItNTEyIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICBzdHJpbmcgICAgcHVibGljIGtleSBibG9iOjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICBzdHJpbmcgICAgcHVibGljIGtleSBibG9iOjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgc3RyaW5nICAgICJzc2gtcnNhIjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgc3RyaW5nICAgICJzc2gtcnNhIjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgbXBpbnQgICAgIGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgIG1waW50ICAgICBlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiPjx0 ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIj cGFydC0yIj48ZW0+IHBhZ2UgNCwgbGluZSAyMTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+ PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSA0LCBsaW5lIDIxPHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFNlcnZlcnMgdGhhdCBh Y2NlcHQgcnNhLXNoYTItKiBzaWduYXR1cmVzIGZvciBjbGllbnQgYXV0aGVudGljYXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFNlcnZlcnMgdGhhdCBhY2NlcHQgcnNhLXNo YTItKiBzaWduYXR1cmVzIGZvciBjbGllbnQgYXV0aGVudGljYXRpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gIFNIT1VMRCBpbXBsZW1lbnQgdGhlIGV4dGVuc2lvbiBuZWdvdGlhdGlv biBtZWNoYW5pc20gZGVmaW5lZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg U0hPVUxEIGltcGxlbWVudCB0aGUgZXh0ZW5zaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBkZWZp bmVkIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBbU1NILUVYVC1JTkZPXSwgaW5j bHVkaW5nIGVzcGVjaWFsbHkgdGhlICJzZXJ2ZXItc2lnLWFsZ3MiIGV4dGVuc2lvbi48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFtTU0gtRVhULUlORk9dLCBpbmNsdWRpbmcgZXNw ZWNpYWxseSB0aGUgInNlcnZlci1zaWctYWxncyIgZXh0ZW5zaW9uLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgV2hlbiBhdXRoZW50aWNhdGluZyB3aXRoIGFuIFJTQSBrZXkg YWdhaW5zdCBhIHNlcnZlciB0aGF0IGRvZXMgbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICBXaGVuIGF1dGhlbnRpY2F0aW5nIHdpdGggYW4gUlNBIGtleSBhZ2FpbnN0IGEgc2Vy dmVyIHRoYXQgZG9lcyBub3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIGltcGxlbWVu dCB0aGUgInNlcnZlci1zaWctYWxncyIgZXh0ZW5zaW9uLCBjbGllbnRzIE1BWSBkZWZhdWx0IHRv IGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBpbXBsZW1lbnQgdGhlICJzZXJ2 ZXItc2lnLWFsZ3MiIGV4dGVuc2lvbiwgY2xpZW50cyBNQVkgZGVmYXVsdCB0byBhbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgc3NoLXJzYSBzaWduYXR1cmUgdG8gYXZvaWQgYXV0aGVu dGljYXRpb24gcGVuYWx0aWVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgc3No LXJzYSBzaWduYXR1cmUgdG8gYXZvaWQgYXV0aGVudGljYXRpb24gcGVuYWx0aWVzLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgaWQ9ImRpZmYwMDEx Ij48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPkNvbnNpc3RlbnQgd2l0aCBTZWN0 aW9uIDggb2YgW1JGQzQyNTFdIGFuZCBTZWN0aW9uIDQuNiBvZiBbUkZDNDI1MF0sPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPklB TkEgaXMgcmVxdWVzdGVkIHRvIHVwZGF0ZTwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQi PiJTZWN1cmUgU2hlbGwgKFNTSCkgUHJvdG9jb2w8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gIHRoaXMgZG9jdW1lbnQgbWFrZXM8L3Nw YW4+IHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mb2xsb3dpbmcgcmVnaXN0cmF0aW9uczo8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgUGFyYW1ldGVycyIgcmVnaXN0cnksIHRvIGV4dGVuZCB0aGUgdGFibGUgUHVibGljIEtleSBB bGdvcml0aG0gTmFtZXM6PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4NCiAgICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+SW48L3NwYW4+IHRoZSBQdWJsaWMgS2V5IEFsZ29yaXRobSA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5OYW1lcyByZWdpc3RyeTo8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgPHNwYW4gY2xhc3M9Imluc2VydCI+LSBUbyB0aGUgaW1tZWRpYXRlIHJpZ2h0IG9m PC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29sdW1uPC9zcGFuPiBQdWJsaWMgS2V5 IEFsZ29yaXRobSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5OYW1lLDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgLSBUaGUgU1NIIHB1Ymxp YyBrZXkgYWxnb3JpdGhtICJyc2Etc2hhMi0yNTYiLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgIGEgbmV3IGNvbHVtbiBpcyB0 byBiZSBhZGRlZCwgdGl0bGVkIFNpZ25hdHVyZSBBbGdvcml0aG0gTmFtZS4gRm9yPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAtIFRo ZSBTU0ggcHVibGljIGtleSBhbGdvcml0aG0gInJzYS1zaGEyLTUxMiIuPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgZXhpc3Rp bmcgZW50cmllcywgdGhlIGNvbHVtbiBTaWduYXR1cmUgQWxnb3JpdGhtIE5hbWUgc2hvdWxkIGJl PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICBhc3NpZ25lZCB0aGUgc2Ft ZSB2YWx1ZSBmb3VuZCB1bmRlciBQdWJsaWMgS2V5IEFsZ29yaXRobSBOYW1lLjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgaWQ9ImRpZmYw MDEzIj48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRoaXMgZG9jdW1lbnQgY3Jl YXRlcyBubyBuZXcgcmVnaXN0cmllcy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgPHNwYW4gY2xhc3M9Imluc2VydCI+LSBJbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhl IGV4aXN0aW5nIGVudHJ5IGZvciAic3NoLXJzYSIsIHR3byBzaWJsaW5nPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICBlbnRyaWVzIGFyZSB0byBiZSBhZGRlZDo8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICBQLiBLLiBBbGcuIE5hbWUgICAgU2lnLiBBbGcuIE5hbWUgICAgUmVmZXJl bmNlICAgICAgICAgIE5vdGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg IHNzaC1yc2EgICAgICAgICAgICByc2Etc2hhMi0yNTYgICAgICBbdGhpcyBkb2N1bWVudF0gICAg U2VjdGlvbiAyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICBzc2gtcnNh ICAgICAgICAgICAgcnNhLXNoYTItNTEyICAgICAgW3RoaXMgZG9jdW1lbnRdICAgIFNlY3Rpb24g Mjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBbUkZDNDI1M10gYXBwbHkgdG8gdGhpcyBkb2N1 bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIFRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBvZiBbUkZDNDI1M10gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFRoZSBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3Rh bmRhcmRzIGFuZCBUZWNobm9sb2d5IChOSVNUKSBTcGVjaWFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICBUaGUgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVj aG5vbG9neSAoTklTVCkgU3BlY2lhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgUHVi bGljYXRpb24gODAwLTEzMUEgWzgwMC0xMzFBXSBkaXNhbGxvd3MgdGhlIHVzZSBvZiBSU0EgYW5k IERTQSBrZXlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBQdWJsaWNhdGlvbiA4 MDAtMTMxQSBbODAwLTEzMUFdIGRpc2FsbG93cyB0aGUgdXNlIG9mIFJTQSBhbmQgRFNBIGtleXM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIHNob3J0ZXIgdGhhbiAyMDQ4IGJpdHMgZm9y IFVTIGdvdmVybm1lbnQgdXNlIGFmdGVyIDIwMTMuIEtleXMgb2YgMjA0ODwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgc2hvcnRlciB0aGFuIDIwNDggYml0cyBmb3IgVVMgZ292ZXJu bWVudCB1c2UgYWZ0ZXIgMjAxMy4gS2V5cyBvZiAyMDQ4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICBiaXRzIG9yIGxhcmdlciBhcmUgY29uc2lkZXJlZCBhY2NlcHRhYmxlLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgYml0cyBvciBsYXJnZXIgYXJlIGNvbnNpZGVyZWQg YWNjZXB0YWJsZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ DQogICAgICA8dHIgaWQ9InBhcnQtMyIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFn ZSA1LCBsaW5lIDI4PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0i I3BhcnQtMyI+PGVtPiBwYWdlIDUsIGxpbmUgMjg8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFu PjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRklQUyBQdWJsaWNhdGlvbiAx ODAtNCwgQXVndXN0IDIwMTUsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICBGSVBTIFB1YmxpY2F0aW9uIDE4MC00LCBBdWd1c3QgMjAxNSw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZsdDtodHRwOi8vZHguZG9pLm9yZy8xMC42 MDI4L05JU1QuRklQUy4xODAtNCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICAmbHQ7aHR0cDovL2R4LmRvaS5vcmcvMTAuNjAyOC9OSVNULkZJUFMuMTgw LTQmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgW1JGQzIxMTldICAg QnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBbUkZDMjExOV0gICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIx MTksIE1hcmNoIDE5OTcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Ljwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgW1JGQzM0NDddICAgSm9uc3Nvbiwg Si4gYW5kIEIuIEthbGlza2ksICJQdWJsaWMtS2V5IENyeXB0b2dyYXBoeTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgW1JGQzM0NDddICAgSm9uc3NvbiwgSi4gYW5kIEIuIEthbGlz a2ksICJQdWJsaWMtS2V5IENyeXB0b2dyYXBoeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgU3RhbmRhcmRzIChQS0NTKSAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVj aWZpY2F0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg U3RhbmRhcmRzIChQS0NTKSAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9uczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgVmVyc2lvbiAyLjEiLCBSRkMg MzQ0NywgRmVicnVhcnkgMjAwMy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICAgICAgIFZlcnNpb24gMi4xIiwgUkZDIDM0NDcsIEZlYnJ1YXJ5IDIwMDMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGlkPSJkaWZmMDAxNCI+ PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bUkZDNDI1MF0gICBMZWh0aW5lbiwg Uy4gYW5kIEMuIExvbnZpY2ssICJUaGUgU2VjdXJlIFNoZWxsIChTU0gpPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgUHJvdG9jb2wgQXNzaWduZWQgTnVt YmVycyIsIFJGQyA0MjUwLCBKYW51YXJ5IDIwMDYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gIFtSRkM0MjUx XSAgIFlsb25lbiwgVC4gYW5kIEMuIExvbnZpY2ssICJUaGUgU2VjdXJlIFNoZWxsIChTU0gpPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgUHJvdG9jb2wg QXJjaGl0ZWN0dXJlIiwgUkZDIDQyNTEsIEphbnVhcnkgMjAwNi48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIFtSRkM0MjUyXSAgIFlsb25lbiwgVC4gYW5kIEMuIExvbnZp Y2ssIEVkLiwgIlRoZSBTZWN1cmUgU2hlbGwgKFNTSCk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gIFtSRkM0MjUyXSAgIFlsb25lbiwgVC4gYW5kIEMuIExvbnZpY2ssIEVkLiwgIlRo ZSBTZWN1cmUgU2hlbGwgKFNTSCk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIiwgUkZDIDQyNTIsIEphbnVhcnkgMjAwNi48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEF1dGhlbnRpY2F0 aW9uIFByb3RvY29sIiwgUkZDIDQyNTIsIEphbnVhcnkgMjAwNi48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gIFtSRkM0MjUzXSAgIFlsb25lbiwgVC4gYW5kIEMuIExvbnZpY2ss IEVkLiwgIlRoZSBTZWN1cmUgU2hlbGwgKFNTSCk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gIFtSRkM0MjUzXSAgIFlsb25lbiwgVC4gYW5kIEMuIExvbnZpY2ssIEVkLiwgIlRoZSBT ZWN1cmUgU2hlbGwgKFNTSCk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIFRyYW5zcG9ydCBMYXllciBQcm90b2NvbCIsIFJGQyA0MjUzLCBKYW51YXJ5IDIwMDYuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBUcmFuc3BvcnQgTGF5 ZXIgUHJvdG9jb2wiLCBSRkMgNDI1MywgSmFudWFyeSAyMDA2LjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjcuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij43LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICBbODAwLTEzMUFdICBOYXRpb25hbCBJbnN0aXR1 dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5IChOSVNUKSw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gIFs4MDAtMTMxQV0gIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFy ZHMgYW5kIFRlY2hub2xvZ3kgKE5JU1QpLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgIlRyYW5zaXRpb25zOiBSZWNvbW1lbmRhdGlvbiBmb3IgVHJhbnNpdGlvbmlu ZyB0aGUgVXNlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAiVHJhbnNpdGlvbnM6IFJlY29tbWVuZGF0aW9uIGZvciBUcmFuc2l0aW9uaW5nIHRoZSBVc2Ug b2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQoNCiAgICAgPHRyPjx0ZD48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQ+PC90ZD48L3RyPg0KICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNw YW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAxNCBjaGFuZ2UgYmxv Y2tzLiZuYnNwOzwvdGg+PC90cj4NCiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRo PjxpPjI1IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+ PHRoPjxpPjIxIGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPg0K ICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRlciI+PGJy PlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuNDUuIFRoZSBsYXRlc3Qg dmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYu b3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88 L2E+IDwvdGQ+PC90cj4NCiAgIDwvdGJvZHk+PC90YWJsZT4NCiAgIA0KICAgDQo8L2JvZHk+PGRp diBpZD0iYWJpbmVGaWxsRWxlbWVudCI+PC9kaXY+PC9odG1sPg== --94eb2c1cd6204d625b054ea45e70-- From nobody Wed May 3 22: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 20D78129B69 for ; Wed, 3 May 2017 22:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 TDeyabn-YLLS for ; Wed, 3 May 2017 22:35:45 -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 5A133129B4F for ; Wed, 3 May 2017 22:35:43 -0700 (PDT) Received: from [78.128.48.21] (port=33822 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 1d69QT-003DyJ-49 for curdle@ietf.org; Thu, 04 May 2017 08:35:41 +0300 Message-ID: <590ABDAD.6000900@roumenpetrov.info> Date: Thu, 04 May 2017 08:35:41 +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 References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> In-Reply-To: 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] WG status and rsa-sha2 as public key algorithm 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, 04 May 2017 05:35:47 -0000 Daniel Migault wrote: > Thanks for the file. I'm sorry as somehow is attached copy of another diff, non-related to topic. > Somehow I could not open the file. I am attaching the > diff here. Thanks Daniel. You page to page diff is better then my. > Please comment on the proposed changes. > Yours, > Daniel > [snip] Roumen From nobody Wed May 3 23:35:48 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 9B13D1293E3; Wed, 3 May 2017 23:35:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149387974660.4821.2454166105680073463@ietfa.amsl.com> Date: Wed, 03 May 2017 23:35:46 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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: Thu, 04 May 2017 06:35:47 -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-06.txt Pages : 10 Date : 2017-05-03 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 3 23:36:07 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 9D4F0129B7E; Wed, 3 May 2017 23:36: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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149387976160.4855.4221945931754469319@ietfa.amsl.com> Date: Wed, 03 May 2017 23:36:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-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: Thu, 04 May 2017 06:36:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-07.txt Pages : 8 Date : 2017-05-03 Abstract: This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-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 Wed May 3 23:37: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 DC4E6129BA3 for ; Wed, 3 May 2017 23:37:36 -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 kvPIcMCgOhky for ; Wed, 3 May 2017 23:37:35 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5BF1294B5 for ; Wed, 3 May 2017 23:37:32 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l135so2035001ywb.2 for ; Wed, 03 May 2017 23:37:32 -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=U1KhjxGx+gsQiREtEFjQZTKUzG8OYORJ3qze7auuAtk=; b=n3ZaX5tV36SMZcP0ybDGhJ1wRzX4bu/g4CBs4YVYsdU6/zMNMXhk9feEzoz3p3Y/r6 ts1jVML+wE5qM3x9dxoysH5Vf/Wc6rCPslpiFY1+s2SOYDSRsCnG/ESGN9/uY69SF/dx /ogxDDDKZFB2l7GbNyFFI2ItHk13i9ibP360nkasyON6KxFoc+q2mnVISdYiCeTKUqAm 3Twh4PuOqepPSuoGlyHdW54DBOT2aXJh7zqnnor6B00C2bgDs0yfM+DePKwd+zxgwT6D zhpW86DoXZ7CLTLQ5uGKSyPzxUpfXWbCfwmogcwZhrAcYy3zjvyk9/qp+zglAry2Nghp PErw== 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=U1KhjxGx+gsQiREtEFjQZTKUzG8OYORJ3qze7auuAtk=; b=WLPcgrAslsbHjp73jle22nSuPO5gjuPjmrjco9KOiC6egg7MCV/Df+OUoHxSLW4fW2 SUW5N3B9pybTB/ucIcEyy+xTdNeRQaGDi/ndUiU5lptCDs95gjliq9c/9XD3/TiWPg1D iZzI7nDbsCw+3SskOzJQpCJz2MW5gjxHTsng3G5IkADhOSb9YNod8nCdR4wihnmMb92l crYb1MNrQCr77cpxWSBjIqwVwwGGVLj+p+uvFtpXGwLvkvn7ks2P/qf/VW08t3iISA0y mtcs0cQ3/1SYbgyxgdxIYiQvC2PMGK1l7y46E41U6vQCa1auf06A56vVG2u8x5wiW2y4 A9gg== X-Gm-Message-State: AN3rC/7ndS9yy0EfYLPEsIczqFOTOa/Zjny9+0BYACU21nLnQC+TYpCL uBCIjv2sInvb1ag9EtHCQsEkP5H2rA== X-Received: by 10.129.55.87 with SMTP id e84mr37057552ywa.58.1493879851535; Wed, 03 May 2017 23:37:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Wed, 3 May 2017 23:37:31 -0700 (PDT) In-Reply-To: <590ABDAD.6000900@roumenpetrov.info> References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> From: denis bider Date: Thu, 4 May 2017 00:37:31 -0600 Message-ID: To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= Cc: curdle Content-Type: multipart/alternative; boundary=001a1143fa54e3b48c054ead01fc Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 04 May 2017 06:37:37 -0000 --001a1143fa54e3b48c054ead01fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everyone, in the interest of consensus, I have adopted the requested terminology changes in the two drafts. What was previously "signature algorithm" is now "public key algorithm", and what was previously "public key algorithm" is now "public key format". Please review and let me know. denis On Wed, May 3, 2017 at 11:35 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 wrote: > > Daniel Migault wrote: > >> Thanks for the file. >> > I'm sorry as somehow is attached copy of another diff, non-related to > topic. > >> Somehow I could not open the file. I am attaching the >> diff here. >> > Thanks Daniel. You page to page diff is better then my. > >> Please comment on the proposed changes. >> Yours, >> Daniel >> >> [snip] > Roumen > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1143fa54e3b48c054ead01fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

in the interest of cons= ensus, I have adopted the requested terminology changes in the two drafts. = What was previously "signature algorithm" is now "public key= algorithm", and what was previously "public key algorithm" = is now "public key format".

Please revie= w and let me know.

denis


On Wed, May 3, 2= 017 at 11:35 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0= =BE=D0=B2 <pkixssh@roumenpetrov.info> wrote:

Daniel Migault wrote:
Thanks for the file.
I'm sorry as somehow is attached copy of another diff, non-related to t= opic.
Somehow I could not open the file. I am attaching the
diff here.
 Thanks Daniel. You page to page diff is better then my.
=C2=A0 Please comment on the proposed changes.
Yours,
Daniel

 [snip]
Roumen


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

--001a1143fa54e3b48c054ead01fc-- From nobody Thu May 4 06:41: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 3EF3A1294E0 for ; Thu, 4 May 2017 06:41:24 -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 smZS5XN0b6Yd for ; Thu, 4 May 2017 06:41:22 -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 A306A1294E6 for ; Thu, 4 May 2017 06:41:22 -0700 (PDT) X-AuditID: c618062d-481ff70000000cf0-51-590b427e3551 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.60.03312.E724B095; Thu, 4 May 2017 17:02:23 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0339.000; Thu, 4 May 2017 09:41:21 -0400 From: Daniel Migault To: denis bider , =?utf-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= CC: curdle Thread-Topic: [Curdle] WG status and rsa-sha2 as public key algorithm Thread-Index: AQHSxEPqJvAsBDlj0kyxwsH6Bz54J6HjT40AgACbgoCAABFGgIAAMyoQ Date: Thu, 4 May 2017 13:41:20 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8335@eusaamb107.ericsson.se> References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> 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.11] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8335eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPuG69E3ekwfNLMhZbF85itjh+bi6z xezNe9kdmD12zrrL7rFkyU8mjx+PrzEFMEdx2aSk5mSWpRbp2yVwZXz5+4C5oMO/4v/B/ywN jB98uhg5OSQETCTadzUzdzFycQgJHGWUeHu7hxHCWcYo8XPNJRaQKjYBI4m2Q/3sILaIQLnE qu5bYDazgIxE289PTCC2sICLRN/EHywQNa4Sl89dZISw3SR2rO0Cs1kEVCQerdsKZvMK+Eos 2TaVCWLZDlaJiQ1rwYZyCgRKrJn3D2woo4CYxPdTa5gglolL3HoynwnibAGJJXvOM0PYohIv H/9jhbCVJD7+ng91XL7Eq4lH2SCWCUqcnPmEZQKjyCwko2YhKZuFpGwWIwdQXFNi/S59iBJF iSndD9khbA2J1jlz2ZHFFzCyr2LkKC0uyMlNNzLYxAiMqWMSbLo7GO9P9zzEKMDBqMTDu0CK K1KINbGsuDL3EKMEB7OSCG+xJnekEG9KYmVValF+fFFpTmrxIUZpDhYlcd4J5y9ECAmkJ5ak ZqemFqQWwWSZODilGhj1Tuw8tzrrqPRzhu3aNXu2TLuS/GieNsevKxe8igsPFR7ueBN/qpGX +TtjYP++K5uyXtV6WStEff5jMed16p3P1ySjJ9k65btsitr0svjyifXcGWKsjJu/Jl0pYrjd O+9iwudu87rtO01iZirPEOVZbf3Fz03ORDVoRkjlzJsyt5+lPfbo/vtHiaU4I9FQi7moOBEA 0bwnSKUCAAA= Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 04 May 2017 13:41:24 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8335eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERlbmlzIGZvciBtZWV0aW5nIHRoZSBjb25zZW5zdXMuIEFzIHRoZSBjaGFuZ2VzIGFy ZSBtaW5vciwgaWYgeW91IGhhdmUgYW55IG9waW5pb24gcGxlYXNlIHJhaXNlIGl0IGJ5IHRoZSBl bmQgb2YgdGhlIHdlZWsuIFRoZSBkcmFmdHMgd2lsbCBiZSBzZW50IHRvIHRoZSBJRVNHIG5leHQg d2Vlay4NCllvdXJzLA0KRGFuaWVsDQoNCkZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZGVuaXMgYmlkZXINClNlbnQ6IFRodXJzZGF5LCBN YXkgMDQsIDIwMTcgMjozOCBBTQ0KVG86INCg0YPQvNC10L0g0J/QtdGC0YDQvtCyIDxwa2l4c3No QHJvdW1lbnBldHJvdi5pbmZvPg0KQ2M6IGN1cmRsZSA8Y3VyZGxlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtDdXJkbGVdIFdHIHN0YXR1cyBhbmQgcnNhLXNoYTIgYXMgcHVibGljIGtleSBhbGdv cml0aG0NCg0KSGVsbG8gZXZlcnlvbmUsDQoNCmluIHRoZSBpbnRlcmVzdCBvZiBjb25zZW5zdXMs IEkgaGF2ZSBhZG9wdGVkIHRoZSByZXF1ZXN0ZWQgdGVybWlub2xvZ3kgY2hhbmdlcyBpbiB0aGUg dHdvIGRyYWZ0cy4gV2hhdCB3YXMgcHJldmlvdXNseSAic2lnbmF0dXJlIGFsZ29yaXRobSIgaXMg bm93ICJwdWJsaWMga2V5IGFsZ29yaXRobSIsIGFuZCB3aGF0IHdhcyBwcmV2aW91c2x5ICJwdWJs aWMga2V5IGFsZ29yaXRobSIgaXMgbm93ICJwdWJsaWMga2V5IGZvcm1hdCIuDQoNClBsZWFzZSBy ZXZpZXcgYW5kIGxldCBtZSBrbm93Lg0KDQpkZW5pcw0KDQoNCk9uIFdlZCwgTWF5IDMsIDIwMTcg YXQgMTE6MzUgUE0sINCg0YPQvNC10L0g0J/QtdGC0YDQvtCyIDxwa2l4c3NoQHJvdW1lbnBldHJv di5pbmZvPG1haWx0bzpwa2l4c3NoQHJvdW1lbnBldHJvdi5pbmZvPj4gd3JvdGU6DQoNCkRhbmll bCBNaWdhdWx0IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgZmlsZS4NCkknbSBzb3JyeSBhcyBzb21l aG93IGlzIGF0dGFjaGVkIGNvcHkgb2YgYW5vdGhlciBkaWZmLCBub24tcmVsYXRlZCB0byB0b3Bp Yy4NClNvbWVob3cgSSBjb3VsZCBub3Qgb3BlbiB0aGUgZmlsZS4gSSBhbSBhdHRhY2hpbmcgdGhl DQpkaWZmIGhlcmUuDQpUaGFua3MgRGFuaWVsLiBZb3UgcGFnZSB0byBwYWdlIGRpZmYgaXMgYmV0 dGVyIHRoZW4gbXkuDQogIFBsZWFzZSBjb21tZW50IG9uIHRoZSBwcm9wb3NlZCBjaGFuZ2VzLg0K WW91cnMsDQpEYW5pZWwNCltzbmlwXQ0KUm91bWVuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QNCkN1cmRsZUBp ZXRmLm9yZzxtYWlsdG86Q3VyZGxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jdXJkbGUNCg0K --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8335eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBEZW5pcyBmb3IgbWVldGluZyB0aGUgY29uc2Vu c3VzLiBBcyB0aGUgY2hhbmdlcyBhcmUgbWlub3IsIGlmIHlvdSBoYXZlIGFueSBvcGluaW9uIHBs ZWFzZSByYWlzZSBpdCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrLiBUaGUgZHJhZnRzIHdpbGwgYmUg c2VudCB0byB0aGUgSUVTRyBuZXh0IHdlZWsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllvdXJzLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EYW5pZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEN1cmRsZSBb bWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5kZW5p cyBiaWRlcjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDA0LCAyMDE3IDI6MzggQU08 YnI+DQo8Yj5Ubzo8L2I+INCg0YPQvNC10L0g0J/QtdGC0YDQvtCyICZsdDtwa2l4c3NoQHJvdW1l bnBldHJvdi5pbmZvJmd0Ozxicj4NCjxiPkNjOjwvYj4gY3VyZGxlICZsdDtjdXJkbGVAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ3VyZGxlXSBXRyBzdGF0dXMgYW5kIHJz YS1zaGEyIGFzIHB1YmxpYyBrZXkgYWxnb3JpdGhtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGVsbG8gZXZlcnlvbmUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pbiB0aGUgaW50ZXJlc3Qgb2YgY29uc2Vuc3VzLCBJIGhhdmUgYWRv cHRlZCB0aGUgcmVxdWVzdGVkIHRlcm1pbm9sb2d5IGNoYW5nZXMgaW4gdGhlIHR3byBkcmFmdHMu IFdoYXQgd2FzIHByZXZpb3VzbHkgJnF1b3Q7c2lnbmF0dXJlIGFsZ29yaXRobSZxdW90OyBpcyBu b3cgJnF1b3Q7cHVibGljIGtleSBhbGdvcml0aG0mcXVvdDssIGFuZCB3aGF0IHdhcyBwcmV2aW91 c2x5ICZxdW90O3B1YmxpYyBrZXkgYWxnb3JpdGhtJnF1b3Q7IGlzIG5vdyAmcXVvdDtwdWJsaWMg a2V5DQogZm9ybWF0JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmV2aWV3IGFuZCBsZXQgbWUga25vdy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVuaXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IE1heSAzLCAyMDE3IGF0IDExOjM1IFBNLCDQoNGD0LzQtdC9INCf0LXRgtGA0L7QsiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBraXhzc2hAcm91bWVucGV0cm92LmluZm8iIHRhcmdldD0iX2JsYW5rIj5w a2l4c3NoQHJvdW1lbnBldHJvdi5pbmZvPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRGFuaWVsIE1pZ2F1bHQgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmtzIGZvciB0aGUgZmlsZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkknbSBzb3JyeSBhcyBzb21laG93IGlzIGF0dGFjaGVkIGNvcHkgb2YgYW5v dGhlciBkaWZmLCBub24tcmVsYXRlZCB0byB0b3BpYy48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21laG93IEkgY291bGQgbm90IG9wZW4gdGhlIGZp bGUuIEkgYW0gYXR0YWNoaW5nIHRoZTxicj4NCmRpZmYgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBEYW5pZWwuIFlvdSBwYWdl IHRvIHBhZ2UgZGlmZiBpcyBiZXR0ZXIgdGhlbiBteS48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOyBQbGVhc2UgY29tbWVudCBvbiB0aGUgcHJvcG9zZWQgY2hhbmdlcy48YnI+DQpZb3Vycyw8 YnI+DQpEYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltzbmlwXTxicj4NClJvdW1lbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCkN1cmRsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86Q3VyZGxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q3VyZGxlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY3VyZGxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jdXJkbGU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8335eusaamb107erics_-- From nobody Thu May 4 06:47: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 EA940129601 for ; Thu, 4 May 2017 06:47:16 -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 m6H75rNijwsD for ; Thu, 4 May 2017 06:47:15 -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 613EB129526 for ; Thu, 4 May 2017 06:47:15 -0700 (PDT) X-AuditID: c6180641-45bff70000000cb9-c1-590aea83a726 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 92.6E.03257.38AEA095; Thu, 4 May 2017 10:47:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Thu, 4 May 2017 09:47:11 -0400 From: Daniel Migault To: curdle Thread-Topic: WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 Thread-Index: AdLE3Fc9euaV7RaTSFatYL2+8oh9Rg== Date: Thu, 4 May 2017 13:46:56 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@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_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPlG7bK65Ig5vn1C22LpzF7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHkrfQtemFU83HeTqYHxjmEXIyeHhICJxO6z25lBbCGBo4wS 66ZodjFyAdnLGCU+HvkPlmATMJJoO9TPDmKLCMhIvO6+CxYXFrCTOP7xMVsXIwdQ3Fli3j5/ iBI9iTNvnoKVswioSHx/uwXM5hXwlbi0/j+YzSggJvH91BomEJtZQFzi1pP5TBD3CEgs2XOe GcIWlXj5+B8rhK0k8fH3fHaI+nyJq4sOMkLMFJQ4OfMJywRGwVlIRs1CUjYLSRlEXEdiwe5P bBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLiJERjcxyTYHHcw7u31PMQowMGoxMOr sIozUog1say4MvcQowQHs5IIb7Emd6QQb0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNIT S1KzU1MLUotgskwcnFINjGWS9xMCrY3PdMW8d/rIvTPdtGHlzzcvXP4IhHKEf1ad3G5Y7L7M 6sjzr2mVR7LDLQ5WRtrWrNupM3HS+WOvd7Azbf32S4bpyiHDDov3+3aI3nvCmBK1dcbCw5Oa 1LftWDPN7MSfbVO36xZPOfzm6VTnjh3TTiUeWSiw3Pr+tsMd7Htn89k5LL6uxFKckWioxVxU nAgATEJPg2oCAAA= Archived-At: Subject: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:47:17 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This emails starts a WGLC for draft-ietf-curdle-des-des-des-die-die-die [1]= . If you have any comment please provide them by May 18 on the curdle maili= ng list. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-= die/ [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_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This emails starts a WGLC for draft-ietf-curdle-des-= des-des-die-die-die [1]. If you have any comment please provide them by May= 18 on the curdle mailing list.

 

Yours,

Daniel

 

[1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/=

 

 

 

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_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352eusaamb107erics_-- From nobody Thu May 4 08:08: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 AE336126B71 for ; Thu, 4 May 2017 08:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAGE0gHs5jAN for ; Thu, 4 May 2017 08:07:56 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0116.outbound.protection.outlook.com [104.47.34.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 E1E8F126B6D for ; Thu, 4 May 2017 08:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ax3F91eCKmVRJs9uaaJPMXAjXtebDVh9O3s9ODagQm8=; b=I6JkShwLeCEfGgNXFxVUl6joBsXC90lMlUmBTXsjOzu+r41gVyRvhxmEkPpdAsKGNo5uf1xs4jvTJV4oq8hOaCSAhm1yfPBIJqcruJNbiCkZtw17Dq3eZO8r1NHaMkaRWvYWbuE62RhpiidzNY5EQWjDaWMP9dzx2mxadh6+w8I= Received: from BLUPR05CA0052.namprd05.prod.outlook.com (10.141.20.22) by DM2PR05MB733.namprd05.prod.outlook.com (10.141.178.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Thu, 4 May 2017 15:07:49 +0000 Received: from BY2NAM05FT009.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::208) by BLUPR05CA0052.outlook.office365.com (2a01:111:e400:855::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 4 May 2017 15:07:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT009.mail.protection.outlook.com (10.152.100.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 4 May 2017 15:07:48 +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; Thu, 4 May 2017 08:07:47 -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 v44F7knQ021812; Thu, 4 May 2017 08:07:47 -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 8327711446; Thu, 4 May 2017 08:07:46 -0700 (PDT) To: denis bider CC: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , curdle In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> Comments: In-reply-to: denis bider message dated "Thu, 04 May 2017 00:37:31 -0600." From: "Mark D. Baushke" Date: Thu, 4 May 2017 08:07:46 -0700 Message-ID: <31063.1493910466@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39400400002)(39840400002)(39860400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(93886004)(189998001)(558084003)(4326008)(39060400002)(76506005)(53416004)(356003)(7846003)(6392003)(77096006)(8676002)(81166006)(8936002)(117636001)(76176999)(5003940100001)(105596002)(6266002)(478600001)(47776003)(106466001)(110136004)(38730400002)(6246003)(54906002)(55016002)(53936002)(50986999)(2906002)(6916009)(229853002)(54356999)(305945005)(2810700001)(7696004)(5660300001)(48376002)(86362001)(7126002)(50466002)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB733; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT009; 1:fctdXMc668uX5urgC3giw0TPo7XcOvEMQpy8T0sSBGfMbQwuEp62HXdRruBh75WLLXu5YIkyBLxkBvdajsm/9kmv3mGT4o2K1BTQr0/LBuw+FVpG9HUsmQKCsLFP3N63yIQJ5Qdu4bYNMxfnarrOjkQlaTFDNUhuEMqfrKw49znZQoGkM66v6rhsLyOQKpv6gAy3lrSFFMk+Upc1o9OjBe3f2Rf5zjwKB+B3R8pYYSvQ2vJHVXruMguKs/PyIAOm23pyCo7/ZmnbZok2F8rneezlaFcp4lz0y+Db6VtSkVoV29bBcybTo125SP/DA2mSwFxCeymZrlC0sZV0dARlcK5fe5iPj/Dz+b12uYwlKTt3bacbCagES7fWX1DKB/7PYArkvHUyrALWyTaa7RAsW8UZA+vCrzGNC9I2dK9Hawy/t9d2SuDInXy+NxdOIzajKrf4xTMOkmbMWc0rRXtY2ZHbx3ZaXIOCX+YUCI6tYg7QVou+EtdRk4ziVNxrDMzOeFnGlOc+FAu+6P8ViWwu+vyEmh+zEQgGPcQFVpj4T+z5AJ0vCLY2sXTwtixc+C4B X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dc0a5e2a-aa51-4d78-9cda-08d492ff5420 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR05MB733; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 3:hOtlB7EEYfpHDC/0NbA8iFG7xOvUmkwWfkJp03gjzIFCBXjeoYbTnegQYCiJHrkDB1YrJ/jWUt6JRQvJClGqYLCMhIwzo20ZaG8H2rWNjXGkMNLaXHM4pjc1GOeliNXdenarsfS4jXSqjOIAiHMkL5282/mUvjCxA+JTBlOPEGB72ltEJl86tS53QX/+pmaPWpMZChFyltDNfEW2/e0VaeugdVCFMSG9RaNfECgouvvOhd7Fu5H8GgXHjnyKc3YOFYr7URjtMIEhbM9eiGBrnvoO9kGvBUINlErL3akzwkXEyz7abaS+S5aWtAe4y+yIN6l1aTsb5d0S9DleJl8bxPKL1EWU6YGYciIg1NJxrZirFBCM2LUuhVsR2HUUzaiNJySZ5EHMHIltqWrEKiWGjRExwhuapJjqeNy2J9ctcIwVAr48UpNMhntJaj16t6uYwg+iUZ7hC/op2dgWOi582Q== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 25:cXXfwwRF5umjC538J0xIsubjm9iqTq5dS4ujvycFEc8aTFVAceHS7QEG2p26QjAJlbdWSZGggQDGtVPXOJKdVocBk91cHeGNIoro1TBygvLu6EpDmrhG3imtyc+UsPE96N7zLcCJJ1qTkeWb+OHRAeBSyYzgAcIHbGdQPN3AM2y6HqDL1F86m/vmWfiaXjTMT8EUE+VpQWEde2KIDgEF0dUr56wX6xPlmvMf6U9Xh8zeo9yEgs2ZE6msJWu+tmeNXQ3ZoPyguucPW2Oz1dwyM2xBkSuwv7zqJRocxq18I7CyNKcxfV6y1pYVziQry6vM/7MMpykz8b9F3RU6UyRq3qIo+t1jgynhiTYr+7gWqhmUCIQdQ6AIZrLvdhxZZnt2hfOycxdRu5h4Gdo5ORmiyAQaX12zJ/y7QVsicACDm5ZTbnsyU4hMNxueb5uf6BsW03BbhPKcjSLyT5Bmb5Chyh0U/LRR5QukhaLf6r99ayg=; 31:doQDyFwGm28USDHdw2DAuKq2MEM2OlrkseDNeoZdVhydt+ML1FcA38WsQ02AvWjz/s9cYULHbopuAjKFlGGvQpEtLAS5d+GUg8xxX4faBDRriZ+lRarNWrD3AfiAATg52S4G7btfQFkp2HZE2VPgYsC+GXh0k+SCvWNEsPLgHqeFocDDaG2q+9c1gWONu0NAhlwtQbZojZWnQT5Nmo2eJqeba9KhJlOW4J8CpehT2HZq1O8s2nB1NDJb7H2oqcXGNAIIk/pJdcYRf7YmdKWm0g== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 20:0HnuupYy6UGXgyV+5ihELkSCx1BOzTvtdeDg3lbyCoDsmDF+bHfZizxfyIzyTAhgZRS5YySuljxOwSHhl9cneKcHFkTC9Q/v56aHDaroma/OBXNsAxZ8Q/bQVyzrqJoXhrFLp7oQaguN1o68tAAjThGFRmbinNj1WHQiEPACGidMpNysarIGm2VTCvf5jN+/3eYP73EWwBNddIcypE3TR+gb36UxtJhkbNazdfaJZzgPfppiT95OcSYyr2eANoBNV4YR6GoJ+4sBeGwauhaiaPNngED0lkfxOUy1XRo0983OqfRa2FzVbc7JyxRHh/1erBrYsTPCx67qev00sJeF5MMJ4hdKMMa4/dlbMS7HkBqzsOCrifLd8nYGJ4aLNHajHdkXSxLhuTLkEcsmm0xhneAnDdJcJaLQvUp0ZsPpwotoEBnMQFk9GSykZexS/CffvRGeIcvMMdBfdzCxcPdry20RGZk0LW+DrXIlQsGMDkR0+d1bM9F5C1BqB2qo6B4x X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13023025)(13024025)(13018025)(13015025)(13017025)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:DM2PR05MB733; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB733; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 4:kTrX14rNqEFpJ7qwCNKp39P0k7nB7MEXrBKQZJ4L+R9z6fr2nnhFeQamkmpBvH7luKt2YiDZ/pfa6vXJPRvfxx65p4PQwdgMoIlxqQBTbKXx51TeIaUnCjkl0CSXahvhDUXIWd9KJMnqfHP5OflMzvmlILU6jobnNJRxIBempW4BaDeI2FlLTp4bF72T4P6MWp4dv6KS1GOmY7QNWgUt9zokknNn6Qy3hVMUhlnYSoW33X2iADLCSNM1Zc2X1aUWdZEqvMC1GrI3EyDBe7j8ANIb78HBk/12RerLDfFJu0po5DQorogc+PWhYHI6qeI+tdK/P3u4yDV5mK8RNJTiwjGrlNT8CfiTG4F91nRpsQf12GCXYPA0J18RuMDas+H5jZicVTluzezSdxBxrC0kojNhA0pSU/A9vZ2BZN7+i+mQMent22pdkXZKIirdcF6GEb1jZJohHQrih2V0uGBpu6D30Wj+HWaiEuEE/2OGPd+qnHoe+bff0gfjKMF/6l7a1cMWL5ZQc3g5iYlppNffTuYBtSmYANyQFGDMgR5EAZ/CK2nONGTXV4/AQ3pqkJTOCgCkI33AWcFVU69rwKeuPb78w8lqiAvxd8VFIJxUFpAiM4e4d5P0MC3sdn2x92+XRIRSK+Jzj18YNYx8e3CuOcNnHLETgwgmJ7QpxLvnRWD3hciafoPXoO7IS+N19pr1aqsVeF5HvlodPYEmkHWkwrWpJXXAXEOhbK7TjRIzVkaZvuGR7RQjJXvm8gO8d9fHZL5Au0XQspJ16/ssRZVIk/H8/9HNuERRWEbP/belop8kFywLMiGWjd4l1usTq3JNfLniOodukpAiAEsiiMMsoi4zj/ah2/paHVdnkWUtyiEmvMrQSLXMgENmlpdbLowMykSzjnuCf+jNmTo3sltXQA== X-Forefront-PRVS: 02973C87BC X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB733; 23:cjt6tp0UDLAjQq2A9GZBdWSl+LtZ3SXfX+odI6iDCW?= =?us-ascii?Q?EnSR897Ye1dE8EDQnmhinLsTCKZ8x6e1GZwfP3TrCsPghiNsb/qwVL7PHdnc?= =?us-ascii?Q?y4nopygU6B5vmcSY9yzGAGXv+OVajFt+KLnzjqWkWmhiTpFmpdqjUP6LonrD?= =?us-ascii?Q?fhBauFULb8Hs7pOX6WCuVpxdXTbIj3XJqjbSrHnYUlw9oVgU3Cs19vKJz/KJ?= =?us-ascii?Q?dZxLfPVhj3L2MAqpPi2EnWz9ho32ua+OPw2k5wg56JpryD/Ye+xvHnBymV4B?= =?us-ascii?Q?INfRYuIKUoR6x7Hl2oP2zgu4rVB7k/u77cYlSNICQ366FP/E0drwo+esfhrs?= =?us-ascii?Q?UPcLdgb7LZkMorssft4Kgo33cnlh7UJGF1YrUVacGKncRJXIgzArIR54WvBv?= =?us-ascii?Q?5kNRUoGIXH9PtlVxDNSEoehvGpnrdiXdMoSYsyK0nvwN/e8B/KXTQDDtM7Iy?= =?us-ascii?Q?dSk4LCaXEjpjilBwV8ehBSmzcnRlKhGyvUXC2S3uUPH/mcjL7j1ztjAEVDSF?= =?us-ascii?Q?yp29mu2lEjqhDla7KVb2yNlXoyVF0Se2PsGf9q9QTfe/bbTEP0j3j1dvcUWm?= =?us-ascii?Q?cA6qUXSxMjw1pKMnPSFF+c0mI9Tp6ORWYGWVjbi7Czl3nnDJb1XNPrb/YCBc?= =?us-ascii?Q?2aDzC3Zh+SA3azb7yekWvwwJg5Um3/W8ejuWTgaJJXAw3E/uE6in0t+LTWbl?= =?us-ascii?Q?eqZQr9XDlDgrV3jXDNGvIjhnQNrLfAjlcNbY+qWAqYjPs7hHnP6LO6/MK0b2?= =?us-ascii?Q?aSPignItEfXLmgQjIcv/Y8BR8/wrHb7bkfquMffk6OaV/euY5u97WUKvwWbe?= =?us-ascii?Q?PQy+zmt1QHwWkbbx/Tl6pSCFNv5fvq39HbLUiHFgxx07Q831kH718dPHOo+8?= =?us-ascii?Q?5+R1V8OwDNMSI0pga+cYnWSsYfvyDij4+EevJ6THDx5g9fj0Vcx1GU+4Fa+8?= =?us-ascii?Q?38jPtHJIk2No+AsPH6E++AgX8aMxZAtWv4hxmNPBK4AC/xnPLgprv05UHd0r?= =?us-ascii?Q?lf+GKSuKkI27V5zTXALgU82vzDPjnmCpzGV07xkedeaBpcnCCzTUDhysWyYi?= =?us-ascii?Q?axFCsUwaNUD4qRrdpIYp+/UelQvUiwmjzUIrShT7zdX9g48fQzFqgD1m412L?= =?us-ascii?Q?CGESgN9rq+zI7u/d7KWQBXCGlbuM+qWLn4xDOmn1kFIJqJN5XHoNS/8AYbt7?= =?us-ascii?Q?po+mjBclyLHBqxDJwigIfgQTsMEnCkP9wcUjCBZKsT65xhrjUPpI3u5UOp9a?= =?us-ascii?Q?ClX+XwaKWSfpgn0GtquGFlJV/k2mciqX47PayJh6NoCsuYxKUIC1IewYjAhN?= =?us-ascii?Q?sUH57JG2cxjJrb1/40kPAF0ZeW6gmEtRNVdeq4Pjj5?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 6:9HWGF9C54BpBQBaL89sBB6ICJ5UTpxNXR5KtNadJWeGwkI4VHST8whAuQgI/HVOFetRp8nkddD9PojP6HF5nmO1buKLRPHQTBsBvqx+uA2H+LG0M4bIbMOfUwBiwoDQFbQgWdciucvU93IE6qWRYsm296ei/aYytjbkekFQGIV5azrpSccBMWDfdUScD045/nz/X0EoHDiNiJowJAG+O0DiTXmGvPZ8JQnf15tA5p2JLEMeOx5QDL7cU6NGC6pWtmXiOJEKaAIN6IOoPKYx+zxfJ/0k1my1RLiDuvcSED/C46JI5BYH0ncqAFRqG96ZFR+MDUnvKS6m6CwOJJO0eHr1lqNPGOs1SbT9MG3I9O8Egx2QhZDNqxL6oY96FHbtl8jgO+Sd6qt1ZFhHsjQog4lE65SHm/x6/XueT6XoSlre8evSZ7+gOsezY9HwDgEckB1d3r4J8pWBjktO2whNYhwPPHZYbd6vMv70m1ej7jWhlMUlbTZoBNKzmUxJt4i7PLN1zKzsgGPqKpBceZ2n52Zj07BNciGb0hZsPWRN1c7A=; 5:7+ujNjw4mkbsu3M8HX7zm2P0E63/FCrobRVK0N4ayxRw5v4sgqfblpaHQIqM66ZA5H22h5JWo/Y8vuw0QHI6pUj35FHHlLxHGcuCv9OvvBftDAC3JI0IZoFE+GfslUeyGXKzNeZaSAi9FAiZXBP95A==; 24:a1rqStkIz0OQeJ9g8afMcyftcRzJgSe9ZqzLZhBNppaYnOiCrREndH1uEvyHX+VE6gaSXSWEtZrk1L1vAZXGOO4d0CSNGeXAJbWHt4IpDKE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 7:s6OhcOlCFK2PDKBvinYvl5nK5KFD2fSAkG6JwvHF/KtrxVTraJdL4ge4C5ex11+yDnu30xwRVCw8zsGG2LZQysse0AFnYxE3Ha/O+uUPZuR5T3eET05JeqnAikRFsUk0W/uDqNth3+YOA5DFiN9hhroi4nbfIk77KjA/pAztYbj7ik4oecAz5CRywzfDApzb6ZZrOBJSpzicNZRPFamJyZnymJwQdLBnv31G7sqop5N28aZeHoL2QuoIEj4EPxLTEgrkn+ia2KhCuVNip78tIo0SHDZ3z50Iv2Q7S8/MPCcE55Ry7I2W9knSrlmbcVOUtMunwFuoNt04PISzTs3Y1g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 15:07:48.9589 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB733 Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 04 May 2017 15:07:58 -0000 Hi denis, draft-ietf-curdle-rsa-sha2-07 looks good to me. -- Mark From nobody Thu May 4 12:18: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 A564612869B for ; Thu, 4 May 2017 12:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 dJKE_ri2blUq for ; Thu, 4 May 2017 12:17:56 -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 CB9B612947B for ; Thu, 4 May 2017 12:17:55 -0700 (PDT) Received: from [78.128.48.21] (port=39090 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 1d6MG8-003Qt9-GM for curdle@ietf.org; Thu, 04 May 2017 22:17:52 +0300 Message-ID: <590B7E60.8000204@roumenpetrov.info> Date: Thu, 04 May 2017 22:17:52 +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 References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> In-Reply-To: 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] WG status and rsa-sha2 as public key algorithm 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, 04 May 2017 19:17:59 -0000 Hi denis, denis bider wrote: > Hello everyone, > > in the interest of consensus, I have adopted the requested terminology > changes in the two drafts. What was previously "signature algorithm" is now > "public key algorithm", and what was previously "public key algorithm" is > now "public key format". > > Please review and let me know. 10x for new versions. Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to list only public key algorithm but this is not so important. The chapter refer to RFC4250 but section 7.1 Normative References lack reference to it. May be is good to list RFC4250 as well. No other remarks. About draft-ietf-curdle-ssh-ext-info-06.txt: The name of extension "server-sig-algs" must be changed as well. First because extension contain abbreviation of signature in name (description is fine), second because existing implementation does not follow rules from RFC4250, section 4.6.1. "Conventions for Names" and third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA signature methods were not being correctly advertised..." fixed in 7.5. [SNIP] Regards, Roumen Petrov From nobody Thu May 4 13:57: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 BFF8A127078 for ; Thu, 4 May 2017 13:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Uq1LCpJb-H29 for ; Thu, 4 May 2017 13:57:21 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 43CCE1294AC for ; Thu, 4 May 2017 13:57:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from thunderbird-2.linux.ds.cam.ac.uk ([131.111.9.24]:59270) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1d6NoK-0001gk-Qi (Exim 4.89) (return-path ); Thu, 04 May 2017 21:57:16 +0100 Received: from bjh21 (helo=localhost) by thunderbird-2.linux.ds.cam.ac.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1d6NoK-0007Yt-6M; Thu, 04 May 2017 21:57:16 +0100 Date: Thu, 4 May 2017 21:57:16 +0100 (BST) From: Ben Harris To: "Mark D. Baushke" cc: denis bider , ietf-ssh@netbsd.org, curdle In-Reply-To: <17136.1493159459@eng-mail01.juniper.net> Message-ID: References: <53117.1493095177@eng-mail01.juniper.net> <17136.1493159459@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: "B.J. Harris" Archived-At: Subject: Re: [Curdle] eddsa25519 & eddsa448 for use with SSH 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, 04 May 2017 20:57:24 -0000 On Tue, 25 Apr 2017, Mark D. Baushke wrote: > denis bider writes: > >> I believe the spec for ssh-ed25519 is already an active draft under >> the purview of Curdle: >> >> https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 > > You are correct. This one is expired. I wonder if Ben Harris is likely > to resubmit it? I'm not in any imminent danger of doing so. If someone were to pick it up and make it useful I would be very happy, but I'm a bit short of energy for navigating bureaucracies at the moment. -- Ben Harris From nobody Thu May 4 22:12: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 5FC001293E1 for ; Thu, 4 May 2017 22:12:57 -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 t4f8IYuDtbJI for ; Thu, 4 May 2017 22:12:54 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 E94B71293F9 for ; Thu, 4 May 2017 22:12:53 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l135so16225118ywb.2 for ; Thu, 04 May 2017 22:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DHr7fmcgk0KWpisd9pWfdW2/659dDXxyiyaZaB79Yks=; b=m/QNoPJKhfmP0tdVsGSvRfuUK5hE96bY3udOp2wlqDSQyskmDarJQzMkBvC43Sz/aA KW/jFKrAJ1OmadkrbCHPfbM2dvzJDHK6cWR211TA1f2QiarxIjUDpXAmJ4+vF2N283aL taTXbF+R5Odv0SkgStTYDdCGlL9VW+hFduFxiNFvIeLwIKVEK/dSuo86wr3hwrGqh5nJ 7Mo1R9kQyyNJ29B0j2istXhEC2tPzAhIubAHFCAf4wN6d2R1D//1fadzmRBUaGCGQuCV J75vPNVZg4+WWFY4DlaV+2/6zsx7TU0h3/1nObxZQ+eZhmECj6AxYwvFAic9jNIXmu+A oAFw== 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=DHr7fmcgk0KWpisd9pWfdW2/659dDXxyiyaZaB79Yks=; b=qmQQ1cKlnFrBZTGrtNt31Hwtlqhy8ck0w2UxxwWtcPnqe+zsdWR2r0Eqv+AlartIyL 49n5skHn9VX9CrUhBOI1v/OBGMnoLmc8Hwcu+sBgqkU54EAjWspW0xQbbiFEiukeNndf FOIiufXEu2gjyLmmHNxPApevuuGVTkkU59ndLJX0bXpz1rYQ+rpEZPyfRflj0D6BC7r+ qTn6jTJsomUmFROGEXaHF8esI9WnIY5S8IKo4RuUnZVEqvCTROABzST3s0gM9pdTHEjC wgLrU3JzLo8VT3dAz+f+FiJ1kRSJYSHV3QKrK9rIY5EDOwA/08psOsemU6ysrAL8Ykp1 4yYg== X-Gm-Message-State: AN3rC/7jwVfluDpH5DK7wVeX/uVkFKsvT1yI1om7RaZq1pqfvS92+0Zz htZPHqbSwqxjVlotoilPJ0tGZ0qx4kL7 X-Received: by 10.129.172.65 with SMTP id z1mr13584866ywj.237.1493961173151; Thu, 04 May 2017 22:12:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Thu, 4 May 2017 22:12:52 -0700 (PDT) In-Reply-To: <590B7E60.8000204@roumenpetrov.info> References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> <590B7E60.8000204@roumenpetrov.info> From: denis bider Date: Thu, 4 May 2017 23:12:52 -0600 Message-ID: To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= Cc: curdle Content-Type: multipart/alternative; boundary=f403045ea26e08b989054ebff112 Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 05 May 2017 05:12:57 -0000 --f403045ea26e08b989054ebff112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 10x for new versions. You don't even have the decency to spell that. > The name of extension "server-sig-algs" must be changed as well. No fucking way. Fuck off. On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5= =D1=82=D1=80=D0=BE=D0=B2 wrote: > Hi denis, > > denis bider wrote: > >> Hello everyone, >> >> in the interest of consensus, I have adopted the requested terminology >> changes in the two drafts. What was previously "signature algorithm" is >> now >> "public key algorithm", and what was previously "public key algorithm" i= s >> now "public key format". >> >> Please review and let me know. >> > 10x for new versions. > > Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. > I still think that chapter 4 IANA Considerations could be simplified to > list only public key algorithm but this is not so important. > The chapter refer to RFC4250 but section 7.1 Normative References lack > reference to it. May be is good to list RFC4250 as well. > No other remarks. > > > > About draft-ietf-curdle-ssh-ext-info-06.txt: > The name of extension "server-sig-algs" must be changed as well. > First because extension contain abbreviation of signature in name > (description is fine), > second because existing implementation does not follow rules from RFC4250= , > section 4.6.1. "Conventions for Names" and > third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA > signature methods were not being correctly advertised..." fixed in 7.5. > > > [SNIP] > > Regards, > Roumen Petrov > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045ea26e08b989054ebff112 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A010x for new ver= sions.

You don't even have the decency to spell= that.

<= div>
>=C2=A0The name= of extension "server-sig-algs" must be changed as well.
No fucking way. Fuck off.



On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5= =D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 <pkixssh@roumenpetro= v.info> wrote:
Hi denis,

denis bider wrote:
Hello everyone,

in the interest of consensus, I have adopted the requested terminology
changes in the two drafts. What was previously "signature algorithm&qu= ot; is now
"public key algorithm", and what was previously "public key = algorithm" is
now "public key format".

Please review and let me know.
10x for new versions.

Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to lis= t only public key algorithm but this is not so important.
The chapter refer to RFC4250 but section 7.1 Normative References lack refe= rence to it. May be is good to list RFC4250 as well.
No other remarks.



About draft-ietf-curdle-ssh-ext-info-06.txt:
The name of extension "server-sig-algs" must be changed as well.<= br> First because extension contain=C2=A0 abbreviation of signature in name (de= scription is fine),
second because existing implementation does not follow rules from RFC4250, = section 4.6.1. "Conventions for Names" and
third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA sig= nature methods were not being correctly advertised..." fixed in 7.5.

[SNIP]

Regards,
Roumen Petrov


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

--f403045ea26e08b989054ebff112-- From nobody Thu May 4 23:18: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 B72FE1293F9 for ; Thu, 4 May 2017 23:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uazi77IVBUfe for ; Thu, 4 May 2017 23:18:18 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5E4127097 for ; Thu, 4 May 2017 23:18:17 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id p143so8647284yba.2 for ; Thu, 04 May 2017 23:18:17 -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=usQO++vd4njiCQY7rra/iK0N5u4JDN37G3eIWKHNMbo=; b=LykUXsyOzOHDiW8wiaYNe3sQ6pcMO0duJ54Ha4zoepVOi1dquJ+zURNSMg8RL61qVg SwEvX9D2O7OsogT2LDWUReN8BCqFouKLjCnyHcJtsVOMC6O1hNUnV1vrbBtYHN8EvbTg 4eK3f+3qn/xkmWIfa3Liejkp5xuN1HWd2JzHpvWoK+DqK75aZ+n4ZKGaZ7rv2QbtoJqI pnwx8j0aYzX3gk9B8YIJfAIb00FRW4Tbqt47sJpSsfAxVJ0+BgoiH0erFSHvZ2lS2jhq H8qHC9tHXY81dIS1m4r1gH5fBMcLRoWdXAAk6tzqoYjwkt7Gkf0ymXatoVgG1oN3qbGe rppQ== 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=usQO++vd4njiCQY7rra/iK0N5u4JDN37G3eIWKHNMbo=; b=HsOFBKxiea5BGGCs6kw867sHU5kjOvDn0Lj6TsqxOHkw2cLd89v/jaLs6El9xoh1ml gTJZHbrVfynqlxnaASUbsdPwaO0xL5XMTC+s91x84L/HiPZZZ4wIUhUOyVFBgaplWHel wQCMaJsGTiWXrAQvNJ5P21GeX+0LbX/i+cVwQ8XUFja51mkBmPAHStWc67Tfj8w2w5Xf 0jwQc/mCA0eliE+Zo2RQbYiiPXxCrxjekDNUtzYoAye7eCMOpAT7qp2IxtVQaeqx5X54 w6fiB9Q5s+nqrV2kd7igByjU/IHpQYy60AZ6FKOmteBK4TdeofH/yJibfLEITaeYfe/s Agjw== X-Gm-Message-State: AN3rC/5S4FNCzko/fRDYW7DaPKYpY+cQzPzkJgS94oVDQxmDzX0sW51h pC7Z74/TbSCYPfcAH3WE/rzogIQVSs/v X-Received: by 10.37.42.81 with SMTP id q78mr39060119ybq.31.1493965097072; Thu, 04 May 2017 23:18:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Thu, 4 May 2017 23:18:16 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> <590B7E60.8000204@roumenpetrov.info> From: denis bider Date: Fri, 5 May 2017 00:18:16 -0600 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a1143f9ceeb0116054ec0daca Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 05 May 2017 06:18:20 -0000 --001a1143f9ceeb0116054ec0daca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Although my below response was self-explanatory, it is not sufficient. It requires elaboration: - The extension being specified is already deployed in a variety of implementations, not only OpenSSH. (See [1] at bottom) - Since the draft thus far remains compatible with existing implementations, changing the name of the extension would break compatibility. - Breaking compatibility with existing implementations requires a substantive reason. I am currently not aware of a substantive reason to do this. - A problem in particular versions of a particular implementation is not a substantive reason. Idiosyncrasies of specific implementations are handled by others recognizing the SSH version string, not diverging the protocol. - It is not clear to me that the problem you reference in OpenSSH versions prior to 7.5 is a problem that needs to be addressed at this level. - In a previous message, Damien Miller, who is representative of OpenSSH in this forum, has expressed a preference to keep the same extension name. To be clear, the extension name is not one I'm overly happy with. In fact, I had changed the name of the extension from "server-sig-algs" to something more appropriate in an early version of the draft. However, by that time, another implementation already picked up "server-sig-algs". For this reason, I changed the spec back to "server-sig-algs". Although the name is not ideal, it is now in use; and the name being ideal is strictly less important than there being one identifier; and one identifier only; for the same concept, if reasonably possible. I stand by this decision, and think it's incorrect to modify the name at this time, unless the mechanics of the extension are changed in some way that's fundamental. [1] According to this excellent, but at this time slightly outdated comparison: http://ssh-comparison.quendi.de/comparison/hostkey.html ... implementations of rsa-sha2-*** public key algorithms include AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also support them, but this is not listed in the chart. This leads me to believe there may be other implementations also. I know that at least three of these implementations also implement the "server-sig-algs" extension under its current name. On Thu, May 4, 2017 at 11:12 PM, denis bider wrote: > > 10x for new versions. > > You don't even have the decency to spell that. > > > > The name of extension "server-sig-algs" must be changed as well. > > No fucking way. Fuck off. > > > > On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 > wrote: > >> Hi denis, >> >> denis bider wrote: >> >>> Hello everyone, >>> >>> in the interest of consensus, I have adopted the requested terminology >>> changes in the two drafts. What was previously "signature algorithm" is >>> now >>> "public key algorithm", and what was previously "public key algorithm" = is >>> now "public key format". >>> >>> Please review and let me know. >>> >> 10x for new versions. >> >> Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. >> I still think that chapter 4 IANA Considerations could be simplified to >> list only public key algorithm but this is not so important. >> The chapter refer to RFC4250 but section 7.1 Normative References lack >> reference to it. May be is good to list RFC4250 as well. >> No other remarks. >> >> >> >> About draft-ietf-curdle-ssh-ext-info-06.txt: >> The name of extension "server-sig-algs" must be changed as well. >> First because extension contain abbreviation of signature in name >> (description is fine), >> second because existing implementation does not follow rules from >> RFC4250, section 4.6.1. "Conventions for Names" and >> third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA >> signature methods were not being correctly advertised..." fixed in 7.5. >> >> >> [SNIP] >> >> Regards, >> Roumen Petrov >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --001a1143f9ceeb0116054ec0daca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although my below response was self-explanatory, it is not= sufficient. It requires elaboration:

- The extension be= ing specified is already deployed in a variety of implementations, not only= OpenSSH. (See [1] at bottom)

- Since the draft th= us far remains compatible with existing implementations, changing the name = of the extension would break compatibility.

- Brea= king compatibility with existing implementations requires a substantive rea= son. I am currently not aware of a substantive reason to do this.

- A problem in particular versions of a particular implemen= tation is not a substantive reason. Idiosyncrasies of specific implementati= ons are handled by others recognizing the SSH version string, not diverging= the protocol.

- It is not clear to me that the pr= oblem you reference in OpenSSH versions prior to 7.5 is a problem that need= s to be addressed at this level.

- In a previous m= essage, Damien Miller, who is representative of OpenSSH in this forum, has = expressed a preference to keep the same extension name.

To be clear, the extension name is not one I'm overly happy with.= In fact, I had changed the name of the extension from "server-sig-alg= s" to something more appropriate in an early version of the draft. How= ever, by that time, another implementation already picked up "server-s= ig-algs".

For this reason, I changed the spec= back to "server-sig-algs". Although the name is not ideal, it is= now in use; and the name being ideal is strictly less important than there= being one identifier; and one identifier only; for the same concept, if re= asonably possible.

I stand by this decision, and t= hink it's incorrect to modify the name at this time, unless the mechani= cs of the extension are changed in some way that's fundamental.

[1] According to this excellent, but at this time slightl= y outdated comparison:


... implementations = of rsa-sha2-*** public key algorithms include AsyncSSH, SmartFTP, and OpenS= SH. Bitvise SSH Server and Client also support them, but this is not listed= in the chart. This leads me to believe there may be other implementations = also. I know that at least three of these implementations also implement th= e "server-sig-algs" extension under its current name.
<= br>

On= Thu, May 4, 2017 at 11:12 PM, denis bider <denisbider.ietf@gmail.= com> wrote:
>=C2=A010x for new versions.
You don't even have the decency to spell that.


>=C2=A0The na= me of extension "server-sig-algs" must be changed as well.=

No fucking way. Fuck off.<= /div>



On Thu, M= ay 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1= =80=D0=BE=D0=B2 <pkixssh@roumenpetrov.info> wrote:
Hi denis,

denis bider wrote:
Hello everyone,

in the interest of consensus, I have adopted the requested terminology
changes in the two drafts. What was previously "signature algorithm&qu= ot; is now
"public key algorithm", and what was previously "public key = algorithm" is
now "public key format".

Please review and let me know.
 10x for new versions.

Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to lis= t only public key algorithm but this is not so important.
The chapter refer to RFC4250 but section 7.1 Normative References lack refe= rence to it. May be is good to list RFC4250 as well.
No other remarks.



About draft-ietf-curdle-ssh-ext-info-06.txt:
The name of extension "server-sig-algs" must be changed as well.<= br> First because extension contain=C2=A0 abbreviation of signature in name (de= scription is fine),
second because existing implementation does not follow rules from RFC4250, = section 4.6.1. "Conventions for Names" and
third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA sig= nature methods were not being correctly advertised..." fixed in 7.5.

[SNIP]

Regards,
Roumen Petrov


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


--001a1143f9ceeb0116054ec0daca-- From nobody Fri May 5 03:15: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 8358F129494 for ; Fri, 5 May 2017 03:15:39 -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 yl0ygwOY2DMU for ; Fri, 5 May 2017 03:15:37 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F25B129501 for ; Fri, 5 May 2017 03:15:37 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id p143so149057yba.2 for ; Fri, 05 May 2017 03:15:37 -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=bMEP6I29IbkF/th9c179MmRnf1nUEG2d/6mhRr4y8aM=; b=rrRik44DL9lqkRawB1dhMfgnSaoz3bqYhedGRcZ6TjMVUuCz0gbGdCciMUX82ci3jx mtIm+gVZf7lCONFdwUrimHSpEcRndvnW9TPu8vcdRtIXp8Fi/E3UuRn6lYIFMMRXJLW5 dn+m4J1ei/E/LB7Ohl+rqWow166HIlQasupgu/krU0/w9k+hWORBbSrdCe+2uhVFz6If BwwHRyDgavnDSvatXpO6GKL2LfQciIjtNI79/PNNbale5n2M4p8RqhNQgfQOho8mtot4 LWkTWWZjPDAofaSUcHMwlukHPdQZdQOSnu4zrGO/uDNbBII29C3/X2lFqbAjdkJrJz/u n03g== 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=bMEP6I29IbkF/th9c179MmRnf1nUEG2d/6mhRr4y8aM=; b=rYjRNQ/SX2TO2dIByJX9h9gyLrdVSM04ysMF985nzBTZi2hsVlJz7VgsPoM5Rxukup qs3Y+wjeFlShyaho4NsgdrcVSiyO0W0UdaY9qIfcHmVdKv8HzKZr5kGJcPJBHak4+gpf C6tTTr6KRjFdejqrPsEBvjduUsBgrF/RhOM1v4vWZKfM0gBPBPNWx/kZGQsoNfOwqOZT 4R3UpTz8S989x7t5qoj6c79KwEgT/iijSVTWFCJir8ZzAdq1TYcsivXmocgsxHElw8lk N9Y3zPi5II+tlgKw9VYsXnBrt+74BMBQpPn9v5tLk4NYrzhn1bkpQfW78QB4Mw7tCBcm sm/A== X-Gm-Message-State: AN3rC/4C29EGvzSCYeqx1qxTF6Zhf5jGcdUEisuKEx2Ij/pM1/ixm2Y9 6PqhlcogQ9r4CQKubqdQD3WHv488mw== X-Received: by 10.37.64.20 with SMTP id n20mr39460585yba.39.1493979336147; Fri, 05 May 2017 03:15:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Fri, 5 May 2017 03:15:35 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> <590B7E60.8000204@roumenpetrov.info> From: denis bider Date: Fri, 5 May 2017 04:15:35 -0600 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11c029b2a232b2054ec42b1c Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 05 May 2017 10:15:39 -0000 --001a11c029b2a232b2054ec42b1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Talking to Roumen off-list to gain a better understanding of his implementation, and why it has trouble dealing with "server-sig-algs" sent by OpenSSH versions before 7.5. Our implementation does not have trouble. His implementation might though, perhaps due to different combinations of supported algorithms, and/or a different design approach. Trying to understand this better. Will post when I do. On Fri, May 5, 2017 at 12:18 AM, denis bider wrote: > Although my below response was self-explanatory, it is not sufficient. It > requires elaboration: > > - The extension being specified is already deployed in a variety of > implementations, not only OpenSSH. (See [1] at bottom) > > - Since the draft thus far remains compatible with existing > implementations, changing the name of the extension would break > compatibility. > > - Breaking compatibility with existing implementations requires a > substantive reason. I am currently not aware of a substantive reason to d= o > this. > > - A problem in particular versions of a particular implementation is not = a > substantive reason. Idiosyncrasies of specific implementations are handle= d > by others recognizing the SSH version string, not diverging the protocol. > > - It is not clear to me that the problem you reference in OpenSSH version= s > prior to 7.5 is a problem that needs to be addressed at this level. > > - In a previous message, Damien Miller, who is representative of OpenSSH > in this forum, has expressed a preference to keep the same extension name= . > > To be clear, the extension name is not one I'm overly happy with. In fact= , > I had changed the name of the extension from "server-sig-algs" to somethi= ng > more appropriate in an early version of the draft. However, by that time, > another implementation already picked up "server-sig-algs". > > For this reason, I changed the spec back to "server-sig-algs". Although > the name is not ideal, it is now in use; and the name being ideal is > strictly less important than there being one identifier; and one identifi= er > only; for the same concept, if reasonably possible. > > I stand by this decision, and think it's incorrect to modify the name at > this time, unless the mechanics of the extension are changed in some way > that's fundamental. > > [1] According to this excellent, but at this time slightly outdated > comparison: > > http://ssh-comparison.quendi.de/comparison/hostkey.html > > ... implementations of rsa-sha2-*** public key algorithms include > AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also suppo= rt > them, but this is not listed in the chart. This leads me to believe there > may be other implementations also. I know that at least three of these > implementations also implement the "server-sig-algs" extension under its > current name. > > > On Thu, May 4, 2017 at 11:12 PM, denis bider > wrote: > >> > 10x for new versions. >> >> You don't even have the decency to spell that. >> >> >> > The name of extension "server-sig-algs" must be changed as well. >> >> No fucking way. Fuck off. >> >> >> >> On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 >> wrote: >> >>> Hi denis, >>> >>> denis bider wrote: >>> >>>> Hello everyone, >>>> >>>> in the interest of consensus, I have adopted the requested terminology >>>> changes in the two drafts. What was previously "signature algorithm" i= s >>>> now >>>> "public key algorithm", and what was previously "public key algorithm" >>>> is >>>> now "public key format". >>>> >>>> Please review and let me know. >>>> >>> 10x for new versions. >>> >>> Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. >>> I still think that chapter 4 IANA Considerations could be simplified to >>> list only public key algorithm but this is not so important. >>> The chapter refer to RFC4250 but section 7.1 Normative References lack >>> reference to it. May be is good to list RFC4250 as well. >>> No other remarks. >>> >>> >>> >>> About draft-ietf-curdle-ssh-ext-info-06.txt: >>> The name of extension "server-sig-algs" must be changed as well. >>> First because extension contain abbreviation of signature in name >>> (description is fine), >>> second because existing implementation does not follow rules from >>> RFC4250, section 4.6.1. "Conventions for Names" and >>> third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA >>> signature methods were not being correctly advertised..." fixed in 7.5. >>> >>> >>> [SNIP] >>> >>> Regards, >>> Roumen Petrov >>> >>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >> >> > --001a11c029b2a232b2054ec42b1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Talking to Roumen off-list to gain a better understanding = of his implementation, and why it has trouble dealing with "server-sig= -algs" sent by OpenSSH versions before 7.5. Our implementation does no= t have trouble. His implementation might though, perhaps due to different c= ombinations of supported algorithms, and/or a different design approach. Tr= ying to understand this better. Will post when I do.=C2=A0

On Fri, May 5, 2017 at 12:1= 8 AM, denis bider <denisbider.ietf@gmail.com> wrote:=
Although my below respo= nse was self-explanatory, it is not sufficient. It requires elaboration:
- The extension being specified is already deployed in a v= ariety of implementations, not only OpenSSH. (See [1] at bottom)
=
- Since the draft thus far remains compatible with existing = implementations, changing the name of the extension would break compatibili= ty.

- Breaking compatibility with existing impleme= ntations requires a substantive reason. I am currently not aware of a subst= antive reason to do this.

- A problem in particula= r versions of a particular implementation is not a substantive reason. Idio= syncrasies of specific implementations are handled by others recognizing th= e SSH version string, not diverging the protocol.

= - It is not clear to me that the problem you reference in OpenSSH versions = prior to 7.5 is a problem that needs to be addressed at this level.

- In a previous message, Damien Miller, who is representa= tive of OpenSSH in this forum, has expressed a preference to keep the same = extension name.

To be clear, the extension name is= not one I'm overly happy with. In fact, I had changed the name of the = extension from "server-sig-algs" to something more appropriate in= an early version of the draft. However, by that time, another implementati= on already picked up "server-sig-algs".

= For this reason, I changed the spec back to "server-sig-algs". Al= though the name is not ideal, it is now in use; and the name being ideal is= strictly less important than there being one identifier; and one identifie= r only; for the same concept, if reasonably possible.

<= div>I stand by this decision, and think it's incorrect to modify the na= me at this time, unless the mechanics of the extension are changed in some = way that's fundamental.

[1] According to this = excellent, but at this time slightly outdated comparison:


... implementations of rsa-sha2-*** p= ublic key algorithms include AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH S= erver and Client also support them, but this is not listed in the chart. Th= is leads me to believe there may be other implementations also. I know that= at least three of these implementations also implement the "server-si= g-algs" extension under its current name.


On Thu, May 4, 2017 at 11:12 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>=C2=A010x for= new versions.

You don't even have the decency = to spell that.

=

>=C2=A0The name of extension "server-sig-algs" must be changed as = well.

No fucking way= . Fuck off.



On Thu, May 4, 2017 at 1:17 PM= , =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 <pkixssh@roumenpetrov.info> wrote:
Hi denis,

denis bider wrote:
Hello everyone,

in the interest of consensus, I have adopted the requested terminology
changes in the two drafts. What was previously "signature algorithm&qu= ot; is now
"public key algorithm", and what was previously "public key = algorithm" is
now "public key format".

Please review and let me know.
 10x for new versions.

Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to lis= t only public key algorithm but this is not so important.
The chapter refer to RFC4250 but section 7.1 Normative References lack refe= rence to it. May be is good to list RFC4250 as well.
No other remarks.



About draft-ietf-curdle-ssh-ext-info-06.txt:
The name of extension "server-sig-algs" must be changed as well.<= br> First because extension contain=C2=A0 abbreviation of signature in name (de= scription is fine),
second because existing implementation does not follow rules from RFC4250, = section 4.6.1. "Conventions for Names" and
third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA sig= nature methods were not being correctly advertised..." fixed in 7.5.

[SNIP]

Regards,
Roumen Petrov


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



--001a11c029b2a232b2054ec42b1c-- From nobody Fri May 5 12:33: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 A69B8127876 for ; Fri, 5 May 2017 12:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYsBhhl0zgsC for ; Fri, 5 May 2017 12:33:42 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FED126C25 for ; Fri, 5 May 2017 12:33:42 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id k11so7685044ywb.1 for ; Fri, 05 May 2017 12:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ZzU+7h23106vTqpv/Fd4QguPik5NF+vOTQqijvsSysY=; b=DNIXjvn6dulrz58HeyIKAUZJfNfJbSwb2PBkJgRfeFWughF4EkrgOckvj714RNn5zw dIx1w08bGPzyw3lBXhkoQB4DfQc7JBd9XH6lgbWX2R6GydSgk6KiEg++rUvdrJFwe39I sXlA9n3P6+672cZ0MVahSpDEI1l+f7Kv4caJeIeDdndSxNXhMHY3GEb/2vID8Agkmw5n mkN83EMvb86eSYxJ3bdB7w83GprMtA9CirrPjYPTJywOuoLLlW575jozdjYJzeHtXHV7 zNl4moidDl9oPu1WF42ze03GZy8TVTS/QhVW4TEXB4TcHRiBH7F/6gzv7i5ZcfxYUR8y OUdw== 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=ZzU+7h23106vTqpv/Fd4QguPik5NF+vOTQqijvsSysY=; b=ag1GYq8nGrASwNf4WRiNMMFyNvHxg5VglYMIGDdcSQQWZKypBpYQFu5K7EmLeM/t1r wDHJWlWaarYEk7kMRzzs3sNe/p/4TGWmQx0f+74Bg/ZitvTN4vSTy7g8K9yUD6VHkwVR UIg7S5IhNd6xpa4Tor1k1QCSuK0ILAJ6lPhd4tPOPpYKk4eSJvOg231vFemeAjk/P/ly f0rTJtWrBOUSAbcmeiYYr0fvnOx/XUv4lNryHnZunnKcw/h7quh/X9kGq5sZtzESpBtd 97eldu4y/7lS3k4QCbpRZ5nYTvu7f1B4e37ocdbpqcnI6kgRPbVevdoUPqdyPKAlrbC6 4SFQ== X-Gm-Message-State: AN3rC/4/FtTmPz2bw2c2POZpWoLmXbPXF4C/ooOS+f5xKWv647jgatR0 8lXikZH1ANUh2MJAEbA45MsVRTGg4/cbFno= X-Received: by 10.129.52.141 with SMTP id b135mr40414199ywa.85.1494012821118; Fri, 05 May 2017 12:33:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 12:33:00 -0700 (PDT) From: Eric Rescorla Date: Fri, 5 May 2017 12:33:00 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a114089847e3fcc054ecbf73b Archived-At: Subject: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-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: Fri, 05 May 2017 19:33:44 -0000 --001a114089847e3fcc054ecbf73b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Document: draft-ietf-curdle-ssh-curves-04.txt TECHNICAL S 2. The methods are based on Curve25519 and Curve448 scalar multiplication, as described in [RFC7748]. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for Curve25519 and 56 bytes for Curve448. Clients and servers MUST fail the key exchange if the length of the received public keys are not the expected lengths, or if the derived shared secret only consists of zero bits. No further validation is required beyond what is discussed in [RFC7748]. Is any other validation specified? Maybe I'm missing it, but I don't see any. S 2.1. IMPORTANT: other side=E2=80=99s public key and the local private key scalar. The 3= 2 or 56 bytes of X are converted into K by interpreting the bytes as an unsigned fixed-length integer encoded in network byte order. This conversion follows the normal "mpint" process as described in section 5 of [RFC4251]. It appears you are specifying the opposite encoding from RFC 7748 which says: or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + First, I want to confirm that this is in fact true and that I'm not missing something. Second, if it's not true, this needs to be called out in big letters. EDITORIAL Curve25519 provide strong security and is efficient on a wide range of architectures, and has properties that allows better implementation properties compared to traditional elliptic curves. Curve448 with SHA-512 is similar, but have not received the same has not received -Ekr --001a114089847e3fcc054ecbf73b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Document: draft-ietf-curdle-ssh-curves-04.txt

TECHNICAL
S 2.

=C2=A0 =C2=A0The methods are based on Curve25519 and Curve448 scalar
=C2=A0 =C2=A0multiplication, as described in [RFC7748].=C2=A0 Private= and public keys
=C2=A0 =C2=A0are generated as described therein.= =C2=A0 Public keys are defined as
=C2=A0 =C2=A0strings of 32 byte= s for Curve25519 and 56 bytes for Curve448.
=C2=A0 =C2=A0Clients = and servers MUST fail the key exchange if the length of the
=C2= =A0 =C2=A0received public keys are not the expected lengths, or if the deri= ved
=C2=A0 =C2=A0shared secret only consists of zero bits.=C2=A0 = No further validation is
=C2=A0 =C2=A0required beyond what is dis= cussed in [RFC7748].

Is any other validation speci= fied? Maybe I'm missing it, but I don't
see any.


S 2.1. IMPORTANT:
=C2=A0 =C2=A0ot= her side=E2=80=99s public key and the local private key scalar.=C2=A0 The 3= 2 or
=C2=A0 =C2=A056 bytes of X are converted into K by interpret= ing the bytes as an
=C2=A0 =C2=A0unsigned fixed-length integer en= coded in network byte order.=C2=A0 This
=C2=A0 =C2=A0conversion f= ollows the normal "mpint" process as described in section
=C2=A0 =C2=A05 of [RFC4251].

It appears you are= specifying the opposite encoding from RFC 7748 which
says:
=

=C2=A0 =C2=A0or GF(2^448 - 2^224 - 1) and are encoded a= s an array of bytes, u, in
=C2=A0 =C2=A0little-endian order such = that u[0] + 256*u[1] + 256^2*u[2] + ... +

First, I= want to confirm that this is in fact true and that I'm not
m= issing something. Second, if it's not true, this needs to be called out=
in big letters.


EDITORIA= L
=C2=A0 =C2=A0Curve25519 provide strong security and is efficien= t on a wide range
=C2=A0 =C2=A0of architectures, and has properti= es that allows better
=C2=A0 =C2=A0implementation properties comp= ared to traditional elliptic curves.
=C2=A0 =C2=A0Curve448 with S= HA-512 is similar, but have not received the same

= has not received

-Ekr


--001a114089847e3fcc054ecbf73b-- From nobody Fri May 5 12:46: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 23627126C25 for ; Fri, 5 May 2017 12:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji1yMHcaXRbI for ; Fri, 5 May 2017 12:46:51 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A668B124217 for ; Fri, 5 May 2017 12:46:51 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 203so7829123ywe.0 for ; Fri, 05 May 2017 12:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LM5oxb5u7ywTjGplVv0HUghfSYazprASTbQRW/dk4Yk=; b=m/SR7ex8oIcgODJ0PoAySBt5AydnX5dTKS9T7hLPm3HTzjua2Ttxfyxngr3PuZN77R OC7TFYhyIsJdM9RG+SGnlCwJi50cyQpWY/ltN40i0w1CznVbohubKbOBY82NELus+yzO WBZzBt+7ZIWv1FUyUmi9HnWha2T8ERx2JbD4+JqyLBoDurwbJAbz4CLpMNdPxdo1hnjM 9K0J2vYfv6sA2r7Ltgmk1ciN+Vkk08NsEhut6xm736Oti9Y0T0PMuFuAkW9evhOXVLTs k8bJbFX2xJan813rvsEpccIflPvE2G1cSs1KWzTfpzP7Pr2bJcc5cHzcqIEB6p3TKAPG aVOQ== 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=LM5oxb5u7ywTjGplVv0HUghfSYazprASTbQRW/dk4Yk=; b=c5OGo8YnGUKqUtAnazTlgBzxjvoyNIzlMgKRhZOR8cNA+MatbeqlpsRSxfcAcu5NSJ UJdH3Bd2sCeQmuQ3VScAiujGfrLFz4xvi3/fOwU7UCK35msuZCiXiadmA2y8mvY4P2dU zZOH/h9yPYYGbjmeB6K4ARYW5PHnnS9kSn32yCgjIV6LEJY7U2Bv/pu9LmpbMzDaogYC aHvm5vJjY2EMiVAOJoXXJHRYGT2UxUas24o4cpmP/rshseQrjvPVn/0eEWqqddGCKnFH BY8pM0W2x3niwMA942sO91s2UeSh+nNbFn54cnmaXICzvTk4vYuiVHnVPrdjv5PNohyt wWOA== X-Gm-Message-State: AN3rC/4NVMgKOAylquzsL7YM1HX8iQdr2Sv5DTtTy5lBnZhqVD2kryiV DQ0wMyhQ14SbKkoz00PmqcKQwmHl8PIpXRQ= X-Received: by 10.129.104.69 with SMTP id d66mr10726431ywc.74.1494013610833; Fri, 05 May 2017 12:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 12:46:10 -0700 (PDT) From: Eric Rescorla Date: Fri, 5 May 2017 12:46:10 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11490b9a908f3c054ecc26f7 Archived-At: Subject: [Curdle] AD Review: 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: Fri, 05 May 2017 19:46:53 -0000 --001a11490b9a908f3c054ecc26f7 Content-Type: text/plain; charset=UTF-8 AD Review: draft-ietf-curdle-pkix-04.txt TECHNICAL I see that Brian Smith made a number of comments on 4/29. Is the WG convinced that they have addressed them adequately. S 5. The RFC5280 text on {encipher,decipher}Only is kind of obscure. Say that I have keyAgreement | encipherOnly, can I use this key for TLS? one of the following MAY also be present: Am I supposed to read from this that no other extension may be present? I think this should be explicitly stated. The same applies to signature certificates. Also, did the WG discuss whether you should mandate keyUsage? EDITORIAL S 1. HashEdDSA mode with pre-hashing. The convention used for identifying the algorithm/curve combinations are to use the Ed25519 and Ed448 for convention is RFC 7748 seems to use "curveXXX" rather than "CurveXXX" S 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 know what you mean by "even number" but I think it would be clearer to say "an exact multiple of 8 bits" so people don't think you are talking about the parity of the number of bytes. S 13. Diffie-Hellman has two ls -Ekr --001a11490b9a908f3c054ecc26f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AD Review: draft-ietf-curdle-pkix-04.txt
TECHNICAL
I see that Brian Smith made a number of co= mments on 4/29. Is the WG
convinced that they have addressed them= adequately.

S 5.
The RFC5280 text on {e= ncipher,decipher}Only is kind of obscure.
Say that I have keyAgre= ement | encipherOnly, can I use this key
for TLS?

<= /div>
=C2=A0 =C2=A0one of the following MAY also be present:
=
Am I supposed to read from this that no other extension may = be
present? I think this should be explicitly stated. The same
applies to signature certificates.

Also, d= id the WG discuss whether you should mandate keyUsage?

=

EDITORIAL
S 1.
=C2=A0 =C2=A0HashEdD= SA mode with pre-hashing.=C2=A0 The convention used for identifying
=C2=A0 =C2=A0the algorithm/curve combinations are to use the Ed25519 and= Ed448 for

convention is

= RFC 7748 seems to use "curveXXX" rather than "CurveXXX"=


S 4.

=C2= =A0 =C2=A0 o =C2=A0subjectPublicKey contains the byte stream of the public = key.
=C2=A0 =C2=A0 =C2=A0 While the encoded public keys for the c= urrent algorithms are all
=C2=A0 =C2=A0 =C2=A0 an even number of = octets, future curves could change that.

I know wh= at you mean by "even number" but I think it would be clearer
to say "an exact multiple of 8 bits" so people don't th= ink you are
talking about the parity of the number of bytes.


S 13.
Diffie-Hellman has two = ls

-Ekr


--001a11490b9a908f3c054ecc26f7-- From nobody Fri May 5 13:07: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 3968912869B for ; Fri, 5 May 2017 13:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edIuGvJZccQU for ; Fri, 5 May 2017 13:07:30 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1905C124217 for ; Fri, 5 May 2017 13:07:30 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id s22so449042ybe.3 for ; Fri, 05 May 2017 13:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=klgsCdcXaxqoJUH+mOrbJ+K2lW7dYL/Yzz09WlyqBUY=; b=akF7Yn/oJT2d2HFQlFJ02XsGxiDQwWd9BuUatqLrdL45wwqV1JONz2XtodFHvDhOyQ VILiaE86vnUPU6rVo8vmJWh0zukNd++CJdSQdZMknrgJ0y2XO30aSYNg43Rb4wI5tKeJ Aw0qX8wi9KNtiPZ/NAFxkrLO+OPDPTo8CiaqmkdubQAZDe2HltNR3kdwAyAwCj7vxSUa 0PSpdLDfmDWcylmEcYg4VfTI1XpnVb2QvdbZ4MiGvYv9S91isUdhSlZWsId4GMvQxb3q XwOEhynkO7bSU5qhdxSlRGOTxb7VVxANao/nt6RCZ1CmpdCUftZwPP8hkMK0M9mZr2ia JnXA== 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=klgsCdcXaxqoJUH+mOrbJ+K2lW7dYL/Yzz09WlyqBUY=; b=Z7GFnwJJPZe7IiLF9iO+9GvaaM7IpyXhcD/9fL8MaHfk5F+/kdo895ItXrBHdVwKPZ TnGwp081dFwhc/jPH7TYmKfE1wn2J5AQ3ggHVhMp0UXY3b11cvMa3GQts/dCKe4dyXXv r07e6Tj1KUdiVXY6rg6Wvj3dBBOKRHv6eD/j3pdsIhMq6ChI7wTadtUuZ/I7lKXzFGXG CXCGiT1ucajJvPMIvjsznWDPifU6RTukQXVIDzyUA8sTAaXEqLSptckGG87lrKWcAC55 pp+DP+jCplW+k0YA4p2lS+2ta1Kk55N+LUA0DTgbGV0mJFyyVtgVPozclyy5Fd7xp9j6 KKog== X-Gm-Message-State: AODbwcC5pmk4zxCKsGrjADLklQXgMbNVRt0NhQWbAW68gwi3LokLWPf6 Alp3UYGD2QHcMOkI73q3ahQ/RXNM0NnywEI= X-Received: by 10.37.173.21 with SMTP id y21mr344891ybi.52.1494014849081; Fri, 05 May 2017 13:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 13:06:48 -0700 (PDT) From: Eric Rescorla Date: Fri, 5 May 2017 13:06:48 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=f403045db94e5e7f8c054ecc70d9 Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Fri, 05 May 2017 20:07:31 -0000 --f403045db94e5e7f8c054ecc70d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OVERALL I see a bunch of quasi-normative text here, e.g., [CURVES]. Those other curves are not deprecated, but support for curve25519 and curve448 is encouraged. Can you use RFC 2119 language here? TECHNICAL S 2. X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. 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=E2=80=99s private k= ey. As described in Section 7 of [CURVES], implementations SHOULD detect this situation by checking for the all-zero output. Why are you not requiring this check? SSH and TLS both do. The ECC-CMS-SharedInfo keyInfo field contains the object identifier of the key-encryption algorithm and associated parameters. This algorithm will be used to wrap the content-encryption key. For example, the AES Key Wrap algorithm [AESKW] does not need parameters, so the algorithm identifier parameters are absent. It's important that this be clear. Is it required to be absent? Must I check? The ECC-CMS-SharedInfo entityUInfo field optionally contains additional keying material supplied by the sending agent. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm is placed in the entityUInfo field. The ukm value need not be longer than the key-encryption key that will be produced by the KDF. Need not? Please clarify what the purpose is here. It seems like it's to generate a unique KEK. In that case, the security bounds are what, uniqueness? S 2.2. if ukm is provided, then salt =3D ukm, else salt =3D zero zero in this case is "all zeros"? In any case, HKDF already knows how to deal with salt not provided, to that would be easier to specify. S 8. Don't forget to fill in these values. I assume you will do so once IANA registers your code points? S 9. This section is kinda diffident about whether the sender's ephemeral is truly ephemeral. Is this a MUST? If so, please say so. Appendix: How many people have checked this ASN.1 module? EDITORIAL S 2. Please put KEK in parentheses in your first use. S 3. It would be easier to put this above the key derivation stage. Please provide some sort of reference or cross-reference for "kari" KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If present, the ukm is placed in the entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The ukm value need not be longer than the key-encryption key produced by the KDF. This seems to be duplicated. S 5. This also seems to be largely duplicated. Can you refactor out the common stuff. -Ekr --f403045db94e5e7f8c054ecc70d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

OVERALL
I see a bunch of qua= si-normative text here, e.g.,

=C2=A0 =C2=A0[CURVES= ].=C2=A0 Those other curves are not deprecated, but support for
= =C2=A0 =C2=A0curve25519 and curve448 is encouraged.

Can you use RFC 2119 language here?


TECHNICAL
S 2.
=C2=A0 =C2=A0X25519 is described in S= ection 6.1 of [CURVES], and X448 is described
=C2=A0 =C2=A0in Sec= tion 6.2 of [CURVES].=C2=A0 Since curve25519 and curve448 have
= =C2=A0 =C2=A0cofactors of 8 and 4, respectively, an input point of small or= der
=C2=A0 =C2=A0will eliminate any contribution from the other p= arty=E2=80=99s private key.
=C2=A0 =C2=A0As described in Section = 7 of [CURVES], implementations SHOULD detect
=C2=A0 =C2=A0this si= tuation by checking for the all-zero output.

Why a= re you not requiring this check? SSH and TLS both do.

<= div>
=C2=A0 =C2=A0The ECC-CMS-SharedInfo keyInfo field contai= ns the object identifier
=C2=A0 =C2=A0of the key-encryption algor= ithm and associated parameters.=C2=A0 This
=C2=A0 =C2=A0algorithm= will be used to wrap the content-encryption key.=C2=A0 For
=C2= =A0 =C2=A0example, the AES Key Wrap algorithm [AESKW] does not need paramet= ers,
=C2=A0 =C2=A0so the algorithm identifier parameters are abse= nt.

It's important that this be clear. Is it r= equired to be absent? Must
I check?


=
=C2=A0 =C2=A0The ECC-CMS-SharedInfo entityUInfo field optionally= contains
=C2=A0 =C2=A0additional keying material supplied by the= sending agent.=C2=A0 Note that
=C2=A0 =C2=A0[CMS] requires imple= mentations to accept a KeyAgreeRecipientInfo
=C2=A0 =C2=A0SEQUENC= E that includes the ukm field.=C2=A0 If the ukm field is present,
=C2=A0 =C2=A0the ukm is placed in the entityUInfo field.=C2=A0 The ukm val= ue need not
=C2=A0 =C2=A0be longer than the key-encryption key th= at will be produced by the
=C2=A0 =C2=A0KDF.

=
Need not? Please clarify what the purpose is here. It seems like
=
it's to generate a unique KEK. In that case, the security bounds
are what, uniqueness?


S 2.= 2.
=C2=A0 if ukm is provided, then salt =3D ukm, else salt =3D ze= ro

zero in this case is "all zeros"? In = any case, HKDF already
knows how to deal with salt not provided, = to that would be
easier to specify.


=
S 8.
Don't forget to fill in these values. I assum= e you will do
so once IANA registers your code points?
=
S 9.
This section is kinda diffident about whether= the sender's
ephemeral is truly ephemeral. Is this a MUST? I= f so, please
say so.

Appendix:
How many people have checked this ASN.1 module?

<= br>
EDITORIAL
S 2.
Please put KEK in parenthe= ses in your first use.

S 3.
It would be = easier to put this above the key derivation stage.

Please provide some sort of reference or cross-reference for
&qu= ot;kari"

=C2=A0 =C2=A0KeyAgreeRecipientInfo u= km is optional.=C2=A0 Note that [CMS] requires
=C2=A0 =C2=A0imple= mentations to accept a KeyAgreeRecipientInfo SEQUENCE that
=C2=A0= =C2=A0includes the ukm field.=C2=A0 If present, the ukm is placed in the
=C2=A0 =C2=A0entityUInfo field of the ECC-CMS-SharedInfo as input = to the KDF.=C2=A0 The
=C2=A0 =C2=A0ukm value need not be longer t= han the key-encryption key produced by
=C2=A0 =C2=A0the KDF.

This seems to be duplicated.

=
S 5.
This also seems to be largely duplicated. Can= you refactor out
the common stuff.

-Ekr=



--f403045db94e5e7f8c054ecc70d9-- From nobody Fri May 5 13:14:10 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 1A442128799 for ; Fri, 5 May 2017 13:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knxWDU0ZhO5Y for ; Fri, 5 May 2017 13:14:08 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 DF0EC12869B for ; Fri, 5 May 2017 13:14:07 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k11so8140647ywb.1 for ; Fri, 05 May 2017 13:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ZmwSYEB2N3HN5u53vsU89pVHpY8VxlO8wBOmkVPJTeE=; b=kuH2Cn9hsdDvt5FqL5pHOK0cDHP3DR2yJNhFkBJXo/qgFQVCIMWo9kWYqPfFMLfE+O CwwERaANhBKs9AQQbsday26zBcYYxMFryr82xUlO+dryxDtdbyKiRhZ5r5k4t/ipYqLr cz7z6VahAHhGttQab2efrYzyNv60erM82Ss6ihYDFNVKpTJjz9Wl7zHKTePK0jvJxtP4 TgWa0lnU6fmTl3WhQS4jj3yF/+oEs5xDhYLnl+lL1GXSNWPl6fGi7QZ88CoLokI3Pvxt s7H++YHAn6fCka+GZlDuX2JU1jhuXu9Asj8EsembqL7ngp6sfIMTEEaeuc0EOtwxO4SS lmqA== 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=ZmwSYEB2N3HN5u53vsU89pVHpY8VxlO8wBOmkVPJTeE=; b=VQPrq+4LFWTH3HYoX4Fxx37UD92s/kunF+KPO2kRCvDv2dZVVJpUY+IeC1W7L/p9H5 AfchB2RYK4LV3HOQwTLXMi4ojFCGa5RHqDZabetkzoP6TuLht0Nvonou0eqspp3b2KHA T83hcDedAv6uKwaAs3xaIIoeOWRd5f0Hr5sC6aJ8Mfee5ynMdEYp1NhlUnIx9JCJsKfi wfAjEiMyTMQaNeD1exn2u+PHRG79W3j7bah+hzl5YJMonfbmM0smKOJLU3LxiqLqm/uw Bn4qwrLlpEZtN9Pl39v1yxrJPZR89JEaS0qE8ks8fgSljAwjSiwIWNHDtfBe1OHmp+6u tqQg== X-Gm-Message-State: AN3rC/4xK9YJEJntO7+PYRoBnOMK9PlbR3nxNrTO1FBL3moMjkcHA18G nONoATdeWNTjgQKarukVCiMtkbV82jd0baM= X-Received: by 10.129.146.78 with SMTP id j75mr14028624ywg.3.1494015246884; Fri, 05 May 2017 13:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 13:13:26 -0700 (PDT) From: Eric Rescorla Date: Fri, 5 May 2017 13:13:26 -0700 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c09350414ea9e054ecc8892 Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:14:09 -0000 --94eb2c09350414ea9e054ecc8892 Content-Type: text/plain; charset=UTF-8 TECHNICAL S 3.1 and 3.2. - The text here I think means "you can provide this hash and if you do the parameters field of the hash MUST be absent". Is that correct? - Is there some reason to not prescribe exactly one form here? I.e., require id-sha512 (etc.) or require it not be there? - Also, TLS has converged on talking about an "identity" hash for the PureEd forms. Was this discussed and rejected? EDITORIAL RFC 7748 uses "curveXXX" not "CurveXXX" S 2.1 Each algorithms are identified by an object identifier, and the algorithm identifier may contain parameters if needed. Each algorithm is S 2.4. Please note that || means "concatenation" --94eb2c09350414ea9e054ecc8892 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TECHNICAL
S 3.1 and 3.2.
- Th= e text here I think means "you can provide this hash and
=C2= =A0 if you do the parameters field of the hash MUST be absent".
<= div>=C2=A0 Is that correct?

- Is there some reason= to not prescribe exactly one form here?
=C2=A0 I.e., require id-= sha512 (etc.) or require it not be there?

- Also, = TLS has converged on talking about an "identity" hash
= =C2=A0 for the PureEd forms. Was this discussed and rejected?
=C2= =A0 =C2=A0=C2=A0

EDITORIAL
RFC 7748 uses= "curveXXX" not "CurveXXX"

S 2= .1
=C2=A0 =C2=A0Each algorithms are identified by an object ident= ifier, and the
=C2=A0 =C2=A0algorithm identifier may contain para= meters if needed.

Each algorithm is

=

S 2.4.
Please note that || means "= concatenation"



=
--94eb2c09350414ea9e054ecc8892-- From nobody Fri May 5 14:16: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 1ED95126BF0 for ; Fri, 5 May 2017 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4sPTp_6sVl5 for ; Fri, 5 May 2017 14:16:46 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB503124BFA for ; Fri, 5 May 2017 14:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Svw/o0W2oYeE4o6Dc52cZL9jEgmYHVSuTnvhR+xR4ds=; b=VFSYyL2fOEx595WCxMA4l+ngxmVJuImgmw6du8u8j9+5hxrAZ/1ZXs/A5AFifBY2yJDp0vfdJ5M/Vu38YsQNe+puba9SdCLHiC2ZYu8ZwA5crg38gz6uJ3fMiOJHZPoNkvXhswf0g75fYNhaRklQ8o9Jj7dk+oKlsoOfL76sRBY= Received: from BY1PR0501CA0022.namprd05.prod.outlook.com (10.162.139.32) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Fri, 5 May 2017 21:16:44 +0000 Received: from CO1NAM05FT040.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::209) by BY1PR0501CA0022.outlook.office365.com (2a01:111:e400:4821::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Fri, 5 May 2017 21:16:44 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT040.mail.protection.outlook.com (10.152.96.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Fri, 5 May 2017 21:16:43 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 5 May 2017 14:16:40 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v45LGdpP000981; Fri, 5 May 2017 14:16:39 -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 66D1C11446; Fri, 5 May 2017 14:16:39 -0700 (PDT) To: Eric Rescorla CC: curdle In-Reply-To: References: Comments: In-reply-to: Eric Rescorla message dated "Fri, 05 May 2017 12:33:00 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2017 14:16:39 -0700 Message-ID: <7050.1494018999@eng-mail01.juniper.net> Sender: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39860400002)(39400400002)(39850400002)(39450400003)(2980300002)(189002)(199003)(9170700003)(6916009)(2950100002)(50466002)(356003)(4326008)(7126002)(7696004)(110136004)(38730400002)(229853002)(5660300001)(230783001)(117636001)(47776003)(305945005)(105596002)(76506005)(2906002)(7846003)(2810700001)(53416004)(77096006)(8936002)(81166006)(8676002)(8746002)(50986999)(478600001)(106466001)(55016002)(189998001)(23676002)(6266002)(6306002)(53936002)(54356999)(966004)(6392003)(76176999)(86362001)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB729; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT040; 1:uDW2cUTiWepQRx41IDiOHlhWNCOXCnM7KRms5FPmxWlFn0RE3buEzy7TVaprvM8eUDv+E4syljWjtTmn7zx+WMXbZpjlJC5g2VX454p+Wff51F9tqbhnZT1YDZQtVDK6Vl46d1ED/zGBOxjbyrbbLniLnv+AcKj7AJCdPtN5m0sCIaSyZjIuYWHrcxbNIMTce6/krVulSHhowHUHWHlPQIJsldOYdmsJd3ywQr8y/uAN2IruY2HoSbnyCNlprnRvrKpYqDZ9J0Km5CzfekFrBmm2O1osQ2Eq3pGOOb2WpaMNUCnDcMcJeDxXgUJE8riv/G/jRsnVTzhbLzZC9fLlKNpz1LaEGeiER95Fb2Rqah+XS+LXfSDfHxgewoPUdzXFPoSKsypATGFweQJcoXXWGraSnLG/ZKg9AGE2OdwwNZ2fysXNDoV5mHqfyK+o/XdjVmt6KUvyvd4aVAKXaGVvZnohsyimcdbZkU5cZyvWNJ/BKKXUWqokDUp977Zh6s3JKf9yvOE/NvoZrlatJ/EGNG45SN5Qo+jrqkkU1qbdQVBu0ovEdrp7FkUG89hqdyG+OPVPS1HaKO4P2vTuwBE5hRMqchWFiTp4IIf6rKq640g= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 057f7ae6-c5d0-4bee-cef7-08d493fc07f9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CO2PR05MB729; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 3:k9iox0jmEiToOsLCWzR3FPQjaxg6bD3BBuHwxoQmyhe6OqVAVQUSxz2RrEp+3rqmc7DqlCOO/mJmNcr4KjmKv3WXY1kEF+fnj/via84QJuT77apyNAtk+T1TSMdXqQtG2MbQw/EQSvxLJTQADzRxroxVS2RleMWAi90QJNdxNiVRnMNGi2d4nGysFwUalOfI9I2vszFyd5qsgKvWIGhmChyOxuRrXnfYGrxvNW8OMHK6t08y5kVSWWL3rFI3F/D8W4ddqDdtD9LOww0k7FknP4trwqB4bIrHmpdjrhSdNdKwJnQRe0ZtjvxWQ1ms0RZ0FDRqd8otmP29TH+inTn8cZQnJ3vfueCj8VKfWJiIf1VImeU4ctvc/u9SiF4vcU3LYWm+O8rTrBxOi+1WbfhrBUNp/4ZYcz9tuqVrTh5haW2gphtW40fACWHli/2kjL+7UxT+e4H7ZmrLX7dYeHlj5A== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 25:Utss8JTfiSr5e5dYdpCv6jBpET+CVSTGzwBWh0sMKlw7ljpJ5WEJ0bvs5xrkaOVg3GTFbvZp2RO52tJcOnIErzncn+4TgaziwcgOUuRFM5jyyom+UV544HbOeSYA9Rjp1bh+K6DrTlqtUUUCl8OcUUjKmFXsFmE2SJiVcowFnmi44EfdBvcYTZFl/n8ZHf9GpI+3PWrSecBKiN9fZq8EUyK7cEBCoRUWu+EVlCmTTbkvc4QUtEaPdio0cH+b9QydV8poaz3D1NMEBEJTvcqiEotW4enDQNM1or2jtTnmCqafJIewPz5MK3Wd9toNR+EiHtjczJLlWXQ2aR4VokVW4rJdjrFnFb8lKFfgO5XmXbcJLTTbSABFz+V/P/d8NONiufIETckqpMF4gRcUYcaBnIhrm7GEqTDvzGeTBinMRKc5oM53b2R0CvAJ56VYZl1N5/Zvjax99ZTseZVz3/9yp4O+N3Rt3N0BXEohFD/XtDw=; 31:qH2Ji2As8apJJivcTICiVcGXqWeVWSGv9A7eRFcII/vpwG5OXPLwb7Ig4s0ctsB/Rypv1YDdvjjLMnQx1Qp1sQjwRm/yiGn3xdHYHjyvTVwbR+SBRAj/0Gcux+ABlV0LJBTJz5SBUYVCX9StweQrtNDHcGV0IP5UEoeFCU6c3I7c2r8743bJrx2puTonnI7sDWsHT9imPIs27yolJFJQczaN94/v7Vs/9YURdxHFv87LMmfBidoMDVd8gCKNOgmiAnQGCBv2wMImuV84shRUPg== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 20:aOosrpLg+9N1qJXbSjxTkD1nj0FHfvW4e1lUMjzHdJgW5/iWXHpPAK8t2v15mn6bklGCjIDdqV5zylACegkILb44u+s24KhvTUOWsoJvOt8nJ2qa9B1xZ5ia0+1GKDoFWl9B+U2aplBAo7em91JkPdHuDms4j2QLCD12sKUCzO0Hyv33ThH48y4+ACn6ebjqbPn6chhA86sLn4ooh4iReVE+jEOrrGtjTnubPVVt6a5iZxs5SQ7L1pNifwtZfv88BCekDERVLTfEYjeWD0O+ZSCv+Gpja0Z0YyFytAYnQoa2DsIag+k/Trfcl36yJCToXoNcdBoU0O14uIpnRLU3IB6mqr9QluE2orxYgyM+pGv+u4mVrnNrPsGJjP1WXIJmevc+f/zErPIVcmjFY139Bk4NBGNtWkWNjNwW2TntugqFYyckLd1sCdtrHtq4yGZuuzCk2bJwhRZ13oyaraPq6Z0v48TQ8rZAhhG7FDvtSlX0mwv3OhtqWiKraTtQ2T6l X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13018025)(5005006)(13024025)(13023025)(13017025)(8121501046)(13015025)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148); SRVR:CO2PR05MB729; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB729; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 4:4twSeDVsJiakOr3aLmIrr3TzNjCN96OVgLV1IKPxX07Ae3zGfvcVJkbt3NweX36/j9DswwzC6LRGuYfnutKlf5/CtKjLxwxblU9hf7P55W7CCctl+Ik60/MjciGIMjG1geWp/FaOZUbHSjCUZE3iqrifuZzAn4FgOR31+ITZ/BiYt9+6vn6GfuAj26svgLTesIx8J7oqQSZ7I3gwfn+7bPymsVSOvk+pbKIwwPDCM4n12bbXNdhQfaiSV3FvUsouxJbC2WQaq7g5USLgG4gwzAL3v/3kyIg35klsGEwriAQVOKH4mTGFP8aH9EvIpSKnY5hcae52iT7QIIx1yUMuo3B/uw5FhrWjtDIBUiSwne34+tQTpsAiSS2vTIHX/RjIPLB35CxrVjbvkep44IiBem261EEQHCCj7BTfrbDQTkupVefvk/5yMaUGQB37nZPKU0Fb8rpwmmdyo31hzEnGVH1NeonQqg/6BcRXk5j6VNGAnu9f3IhwZ+OrFqdrxyNKdhgYdmcYAtmpfGb7MjrcOMTzJ3AxbnCFwaey8Vd03u0Qj9yVBjX6Nk03bSUYcEvFblkxtJYVyHbtr3K1Tjz7jbOWswiopWthPuH02VaXdafT36SpMs7TsIDXDDlnIKDOB2QYvrvSSVGRiaCDscfEUzSzMLX1YNHWdWH4Dme7VUzl8twunNdp9aR5mDFsqy7mSy2+JHvc/1wXf6zwr2twG/A0s/nYFgXjQx1hwUJ2FlTG3jpqQz0Td3OoYj5ZYvZwr9VbbsLBL/tfEL/1FYLmB2QGZs9zos7lVu/fEMOa42LxgqO2xpataWDIZpQ+tOG1DPMmlsI2AQk1HOlLkWkPf9KK37dMnQNKtOU9Nqq4DDSNr6luR/yBGp1wrzfkWMy7oeAok3SJFFET2zx6uU0EZBcro4rsWNaKL1IECyhq0rDC5GEl6FkBYyqBkVuJIwjt X-Forefront-PRVS: 02981BE340 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUI3Mjk7MjM6dk1Ra2NybUUvMXR2OFRvTzBJcjNubHY5N0Ry?= =?utf-8?B?MEVjOVJUQnhwS0VQeFphcTNoV1pHWXcvWHRseHZOUHlNcU1NcEwyclFVRlpR?= =?utf-8?B?WUYrOEljZko2eTRGOTMvYm9FckZtMmhWS3dKOVhFTEpGaVJkNEZZam5pT09o?= =?utf-8?B?SVQxdTlSelZzbnFFY0Rlc3g4cldkaGw4ZmswbWRKdjExU1BuYVBURWVSM3hX?= =?utf-8?B?RTJ2QUgydUJFSldwdStXeUFDWXMyaDBQY25hSm9paTBJNmVZZGR5aTBRZjRL?= =?utf-8?B?a0xEZnlXVjhRbmZ2RFBZWkxQQXp1enI3MlRzU1dkdGlIb2hpV2h3WWcyckF2?= =?utf-8?B?bjJsUnBpNTBUdXBENUc1UUhkWGRiU243R1BKNmI5eGpMc29SaFVkOW55MHdJ?= =?utf-8?B?SmJGQ3VkYWw5d3FuS3M3MnpBalljNjFxeHBOSzQ5OFpzeERFVGpTbDlteWVW?= =?utf-8?B?a3pVRHI5WFZLVnpZNXVWRGVQU3dyZTdLaUNXTjVlTzhJMkpRN0hNUTQwcHo5?= =?utf-8?B?MDFXbFRKK2VoWXdpTlVOM244WlVQK3oxbWFIYThRMUVYdWtjRHF5eVFicGtx?= =?utf-8?B?M2RVK0QwNThhcEx6OVlDNUhxSC9RVm5VOTNmQ0xRQzNDU2dHY084UHI0Vmxw?= =?utf-8?B?UWFoUEp2ajJOaFRTZ2RmWDFqTkdQQnZZM29adjV0aG5YUFlrZFVSQUhqZnps?= =?utf-8?B?aFgySUkrejQ3eXhBZG9CZm9ocnJSV1Fqcjl3RUxoRFlPdWR3YlM4a1VNUWZl?= =?utf-8?B?aS9EbHd2QjFFL2tLT25lQ1ZoMUM1QmxRZlFCcGlhdE5YNzBhQzlMQnVGSU5K?= =?utf-8?B?Tmx4Q1ZpMDZHZU43M004aWV3cVBscGVHY0kyOWk1ZXBSVWVBcWRNcGhSazY5?= =?utf-8?B?UStCRC9LN2R1WWVLTmVWMlpSU0M2RHZ1UzNWWm9yR3FNU25sdTE0VVNNcjRi?= =?utf-8?B?djcycXZPRUhxRTY0akZWOHlHK0sxZWZSUkg2NGdQY2xKYkhKSEhHNDJQOHUv?= =?utf-8?B?Z01qVjZZKy8rT0tHeHBrV2FMMFJmRVQ5WERQdTZvaFlzLzduRGIvN0haZVFE?= =?utf-8?B?emcxeHVWSVUwY1Jjb0JLSEV6SDd4dnhObHBuRk1Qa3VCNFkyUGlQbkhrOEho?= =?utf-8?B?MVMvTnpQUlJFY1ZxWjY0RVUwYWZ1eXFnT1JDbHJmQWN6VzRDR2pYelExVm1I?= =?utf-8?B?MVVkTUlxbDl1c2dvMTJNblpiaHB1NGZIVUlSZUhFR3M4L3o3QmVuRU0yaUZm?= =?utf-8?B?NmFCQm5NM3lNNkl4cjRXNzZVU0YyTnVJdHpWQm9wa1Vtdlk5WFJGODZXRmVT?= =?utf-8?B?Zmh6RkRXYnVDSkVHV3FNRHk4OUIxaXRQcjlWL2E1UktudXJ3dVlmV1BWOVVB?= =?utf-8?B?Um91U2MyU29aWVgvZStQV2hGaFA1Z3NEQUFWVWRWVVYvRnpXYnN5ekJkckFJ?= =?utf-8?B?b1JTNy9TeVJpSFQ1b2IzWVVhVTFKRFBmMUY4cHI1d2kyeGE0eGc3YWhkV2FR?= =?utf-8?B?aHd2SVg4MjRZZzRrTXN0M204VWRpNGdyM3J2Vm9WVzNzOVBpbFBlVW93QW8r?= =?utf-8?B?QTYzVU1HOVBVaE1EekxaSUV5MTZCZzdFSE1EVk9rQjhmWk9tUjZmTmNUenF0?= =?utf-8?B?VloxRXpZek43aG1mRTN2VTBOR1JmNWVHaFM0bzROZ0RjNllmSXJEUTNXVE9D?= =?utf-8?Q?VPdqz+3r0my/+VDNSBP8zbApEkQagLsmG/qIMm?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 6:h5DjALPCdNZ537zPV83IopefcOuczkw/giiaHee1h+TqI1Bk6CkmwIIC1LIuoX2PjXh7ny15czsQzyZaL2U9w5EDrmH8fwxN4eDYV1qWe+NGsB4/M4BAl0Zy8/HXQw8BK8SsYJh3h+0u/UTdWRcv9V+0qKw8Q8xUQ5kBXCaVTWrufUgORxaf1n75zLv3WeJsg2qmxbZOC0/Axig4Im+v575gRTZO12kZGzEdPPZ4+HcWj9t2IcRCaNxaaUnBPjJpd8Vnb/dEzD7FFrc/0hJZvKLMmB5wArUN7IgDuPXeJCzX5aI19fgT42NkUnFr5XDl+7V9xIR21tJ4gPp/7wZpwF/NLgSOKpZ2upSplNuDJyGHgtHtVpnrbPfcmUCy77082D0XknW4+uKq7LSsvT1dwmbwKFh94jzgqqPioGk5o7UMvJUUAcAPryNYVP6Im9QoCnk6p/N+6tXLhsN2JUq3raPSVBt1wblvhJiXDR0f9wzukw5rugW4EXFHvSdx3H0z9MihjyQNSRF+H0wqLqFoOZ/uFbBu4pC7HjAAZj1yN/4=; 5:qoJRmLdJXffsXRlEULjOCvkm088vo4rhYhOIzUmknQQBdNvvV3TkxR+UUfBED0IVP9QqBfn65iW4sVbxXrXe/l+jjJYWMGGhmUEmjYBp6BO0OJ6DEq1AVx8qTGP6M9sjaXaergifw/l3nUowP+pC0Q==; 24:Q+wFhGuQcnmO/nlCpj9mMoF5SIx9FgOLAyhEtY1XROWAvyBMPoeaLQou6UV3TZQ2MyVQt1CmtkR6DJZv1jNKAGgMK8oZCLf5SxwUBLrRwoM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB729; 7:bTA3QW6XfZF3k73Xa525jbp/VKc72H7taR/e1ERTihsJiRLLmC9e3vYA0LbqZo3/QubOGBlC8YtORhgIBFbCbsZsKXAwOtZOY6tA+PQj3EqY4HSbq3m9HychSyu/FyNeLFj5aPMDOtroFz+Ps1RYl/WKl2NRGwlvhGH+ZsvM3TlDJKjbbHFQI5mzvUqnczvSGrbFsK+FKg0m5ZzFXmWwEBstYS7x+CoJuDLLawhFyXDTSco8w9LmQi35ChsPQHjy2vlZDSmlUd/twJKSOso59nudW06w/T1QQ5CMjEdLJwl5iX2XdWdYuJFhlImIWt3vMo4hrtvO9OE4Ug+Xld7z4w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2017 21:16:43.8263 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB729 Archived-At: Subject: Re: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-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: Fri, 05 May 2017 21:16:48 -0000 Hi Eric, Eric Rescorla writes: > Document: draft-ietf-curdle-ssh-curves-04.txt >=20 > TECHNICAL > S 2. >=20 > The methods are based on Curve25519 and Curve448 scalar > multiplication, as described in [RFC7748]. Private and public keys > are generated as described therein. Public keys are defined as > strings of 32 bytes for Curve25519 and 56 bytes for Curve448. > Clients and servers MUST fail the key exchange if the length of the > received public keys are not the expected lengths, or if the derived > shared secret only consists of zero bits. No further validation is > required beyond what is discussed in [RFC7748]. >=20 > Is any other validation specified? Maybe I'm missing it, but I don't > see any. Hmmm... When I read it, I was under the impression that this was referencing the concept of batched verification via the referenced via the [goldilocks] paper http://eprint.iacr.org/2015/625.pdf reference in RFC 7748. It is possible that my reading is flawed. I am willing to consider alterations to the text to make it better if you have something in particular to propose. > S 2.1. IMPORTANT: > other side=E2=80=99s public key and the local private key scalar. The= 32 or > 56 bytes of X are converted into K by interpreting the bytes as an > unsigned fixed-length integer encoded in network byte order. This > conversion follows the normal "mpint" process as described in section > 5 of [RFC4251]. >=20 > It appears you are specifying the opposite encoding from RFC 7748 which > says: >=20 > or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in > little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + >=20 > First, I want to confirm that this is in fact true and that I'm not > missing something. Second, if it's not true, this needs to be called out > in big letters. I regret that I did not do anything to implement Curdle448 myself. I suspect that only Aris or Simon will be able to be authoritative on this set of paragraphs. >=20 >=20 > EDITORIAL > Curve25519 provide strong security and is efficient on a wide range > of architectures, and has properties that allows better > implementation properties compared to traditional elliptic curves. > Curve448 with SHA-512 is similar, but have not received the same >=20 > has not received Good catch, I have incorporated this change into my copy of the document. I will publish an update after more folks have commented on the points you raised. -- Mark From nobody Fri May 5 14:23: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 41754126DED for ; Fri, 5 May 2017 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zewaUO_06L_1 for ; Fri, 5 May 2017 14:23:39 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 EE661126BF0 for ; Fri, 5 May 2017 14:23:38 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id k11so8839582ywb.1 for ; Fri, 05 May 2017 14:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fDdW00WGQOYV/j4bC2ezt2b9nbB09OnDObjtpEC6ShQ=; b=Vr56mAMNXhUo0/bYRSZz5MZKdWdeXJf83LH/mFXuWD4ysV+XZ+3HVzMG9gFa+x9Xju 1pirwmziaRExXw/5nHeY4dcmGFATgs+UVSziBCBI4QRdCL07zdHXjWYbfFvZifDq4TCG V2U8Sbm7gVKxh8avPye4NVHYtFscKFWK786PPakWe7zD0R5CJmuBbtvH87M3bWQuAiJ+ rGTkmcUMrYHgBOyftHtNxVyhtuBfP8IgslhovI0N2TkwiQsHb2GZPBqFfaWH08y2/fVD oIIR5vLlnMouAiRnlrFCqhyatQHWJvqVgzSQXZJ9dc9wkpJIPnTYIR4wU/wFWo3KdtZk pEKg== 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=fDdW00WGQOYV/j4bC2ezt2b9nbB09OnDObjtpEC6ShQ=; b=YGGQqgSlzw6dE+WoJ0UtT69PoaYXuz20qZVrR3krNzdmz/LtaI+6xGTYarv8JLIjex Oezm7KvrWXilxeN3tTipxvkU5lXZDCVbxAG+gYENj+mAtkWg27M9B+ekqrMy9Iq6OcsP LJQC/8BJDeNabX87D3gQfYUvuFNsA3B6DQyKvE9V+kCvh+MrnAjzM04J2RE3XObIIDw3 VnC/fmwwJ1VUpifwnkZ+EyUOXVVaAUzh3xv55MxEMEBMl3/O3EqU5B8rcXc7Rb3aK9DO nNzxn/35RSZQNhIiJ9nzxRibY5bl8CFblWNMRHOTsiIBLnWWnqr8lmEyS3bCrYmJX/hx TwiQ== X-Gm-Message-State: AN3rC/5l0a7UkKpiyPimlNAcOm70s8/jQE0tbDNSdjmiSedhdQ+wPhBD 1jzh/oQAXSabCmP+eb2SlytVFgblYA== X-Received: by 10.13.245.2 with SMTP id e2mr42431847ywf.270.1494019418206; Fri, 05 May 2017 14:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 14:22:57 -0700 (PDT) In-Reply-To: <7050.1494018999@eng-mail01.juniper.net> References: <7050.1494018999@eng-mail01.juniper.net> From: Eric Rescorla Date: Fri, 5 May 2017 14:22:57 -0700 Message-ID: To: "Mark D. Baushke" Cc: curdle Content-Type: multipart/alternative; boundary=94eb2c08763ab61463054ecd8058 Archived-At: Subject: Re: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-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: Fri, 05 May 2017 21:23:41 -0000 --94eb2c08763ab61463054ecd8058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 5, 2017 at 2:16 PM, Mark D. Baushke wrote: > Hi Eric, > > Eric Rescorla writes: > > > Document: draft-ietf-curdle-ssh-curves-04.txt > > > > TECHNICAL > > S 2. > > > > The methods are based on Curve25519 and Curve448 scalar > > multiplication, as described in [RFC7748]. Private and public keys > > are generated as described therein. Public keys are defined as > > strings of 32 bytes for Curve25519 and 56 bytes for Curve448. > > Clients and servers MUST fail the key exchange if the length of the > > received public keys are not the expected lengths, or if the derived > > shared secret only consists of zero bits. No further validation is > > required beyond what is discussed in [RFC7748]. > > > > Is any other validation specified? Maybe I'm missing it, but I don't > > see any. > > Hmmm... When I read it, I was under the impression that this was > referencing the concept of batched verification via the referenced via > the [goldilocks] paper http://eprint.iacr.org/2015/625.pdf reference in > RFC 7748. It is possible that my reading is flawed. > > I am willing to consider alterations to the text to make it better if > you have something in particular to propose. Hmm.. Mostly, I'm just trying to figure out what this document is saying, because it just doesn't seem clear. What is it you think people should do? With that said, TLS just specifies: For X25519 and X448, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748]. -Ekr > S 2.1. IMPORTANT: > > other side=E2=80=99s public key and the local private key scalar. T= he 32 or > > 56 bytes of X are converted into K by interpreting the bytes as an > > unsigned fixed-length integer encoded in network byte order. This > > conversion follows the normal "mpint" process as described in sectio= n > > 5 of [RFC4251]. > > > > It appears you are specifying the opposite encoding from RFC 7748 which > > says: > > > > or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in > > little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > > > First, I want to confirm that this is in fact true and that I'm not > > missing something. Second, if it's not true, this needs to be called ou= t > > in big letters. > > I regret that I did not do anything to implement Curdle448 myself. > > I suspect that only Aris or Simon will be able to be authoritative on > this set of paragraphs. > > > > > > > EDITORIAL > > Curve25519 provide strong security and is efficient on a wide range > > of architectures, and has properties that allows better > > implementation properties compared to traditional elliptic curves. > > Curve448 with SHA-512 is similar, but have not received the same > > > > has not received > > Good catch, I have incorporated this change into my copy of the > document. I will publish an update after more folks have commented on > the points you raised. > > -- Mark > --94eb2c08763ab61463054ecd8058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 5, 2017 at 2:16 PM, Mark D. Baushke <<= a href=3D"mailto:mdb@juniper.net" target=3D"_blank">mdb@juniper.net>= wrote:
Hi Eric= ,

Eric Rescorla <ekr@rtfm.com> writ= es:

> Document: draft-ietf-curdle-ssh-curves-04.txt
>
> TECHNICAL
> S 2.
>
>=C2=A0 =C2=A0 The methods are based on Curve25519 and Curve448 scalar >=C2=A0 =C2=A0 multiplication, as described in [RFC7748].=C2=A0 Private = and public keys
>=C2=A0 =C2=A0 are generated as described therein.=C2=A0 Public keys are= defined as
>=C2=A0 =C2=A0 strings of 32 bytes for Curve25519 and 56 bytes for Curve= 448.
>=C2=A0 =C2=A0 Clients and servers MUST fail the key exchange if the len= gth of the
>=C2=A0 =C2=A0 received public keys are not the expected lengths, or if = the derived
>=C2=A0 =C2=A0 shared secret only consists of zero bits.=C2=A0 No furthe= r validation is
>=C2=A0 =C2=A0 required beyond what is discussed in [RFC7748].
>
> Is any other validation specified? Maybe I'm missing it, but I don= 't
> see any.

Hmmm... When I read it, I was under the impression that this was
referencing the concept of batched verification via the referenced via
the [goldilocks] paper http://eprint.iacr.org/2015/625.pdf<= /a> reference in
RFC 7748. It is possible that my reading is flawed.

I am willing to consider alterations to the text to make it better if
you have something in particular to propose.

Hmm.. Mostly, I'm just trying to figure out what this document is say= ing,



-Ekr


> S 2.1. IMPORTANT:
>=C2=A0 =C2=A0 other side=E2=80=99s public key and the local private key= scalar.=C2=A0 The 32 or
>=C2=A0 =C2=A0 56 bytes of X are converted into K by interpreting the by= tes as an
>=C2=A0 =C2=A0 unsigned fixed-length integer encoded in network byte ord= er.=C2=A0 This
>=C2=A0 =C2=A0 conversion follows the normal "mpint" process a= s described in section
>=C2=A0 =C2=A0 5 of [RFC4251].
>
> It appears you are specifying the opposite encoding from RFC 7748 whic= h
> says:
>
>=C2=A0 =C2=A0 or GF(2^448 - 2^224 - 1) and are encoded as an array of b= ytes, u, in
>=C2=A0 =C2=A0 little-endian order such that u[0] + 256*u[1] + 256^2*u[2= ] + ... +
>
> First, I want to confirm that this is in fact true and that I'm no= t
> missing something. Second, if it's not true, this needs to be call= ed out
> in big letters.

I regret that I did not do anything to implement Curdle448 myself.
I suspect that only Aris or Simon will be able to be authoritative on
this set of paragraphs.

>
>
> EDITORIAL
>=C2=A0 =C2=A0 Curve25519 provide strong security and is efficient on a = wide range
>=C2=A0 =C2=A0 of architectures, and has properties that allows better >=C2=A0 =C2=A0 implementation properties compared to traditional ellipti= c curves.
>=C2=A0 =C2=A0 Curve448 with SHA-512 is similar, but have not received t= he same
>
> has not received

Good catch, I have incorporated this change into my copy of the
document. I will publish an update after more folks have commented on
the points you raised.

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

--94eb2c08763ab61463054ecd8058-- From nobody Sat May 6 14:27: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 233E9124217 for ; Sat, 6 May 2017 14:27: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 RaoJhitxhNKy for ; Sat, 6 May 2017 14:27:18 -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 8DB131200FC for ; Sat, 6 May 2017 14:27:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F40043004FE for ; Sat, 6 May 2017 17:27:17 -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 Z2gbQMPiWnUx for ; Sat, 6 May 2017 17:27:14 -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 AEE0330024B; Sat, 6 May 2017 17:27:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Sat, 6 May 2017 17:27:17 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Sat, 06 May 2017 21:27:20 -0000 Eric: > OVERALL > I see a bunch of quasi-normative text here, e.g., >=20 > [CURVES]. Those other curves are not deprecated, but support for > curve25519 and curve448 is encouraged. >=20 > Can you use RFC 2119 language here? The text says that other curves are not deprecated, but it is = encouraging support for X25519 and X448. We know that there are some = communities that are not ready to embrace the CFRG curves over the NIST = curves. So, I=E2=80=99d rather drop the second half of the sentence = than change it to RFC 2119 language. > TECHNICAL > S 2. > X25519 is described in Section 6.1 of [CURVES], and X448 is = described > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. > As described in Section 7 of [CURVES], implementations SHOULD = detect > this situation by checking for the all-zero output. >=20 > Why are you not requiring this check? SSH and TLS both do. RFC 7748 [CURVES] says: 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. We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. > The ECC-CMS-SharedInfo keyInfo field contains the object identifier > of the key-encryption algorithm and associated parameters. This > algorithm will be used to wrap the content-encryption key. For > example, the AES Key Wrap algorithm [AESKW] does not need = parameters, > so the algorithm identifier parameters are absent. >=20 > It's important that this be clear. Is it required to be absent? Must > I check? The parameters can be present or absent depending on the key-encryption = algorithm that is used. This document does not specify a particular = algorithm; they are specified in other documents. > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note = that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. The ukm value need not > be longer than the key-encryption key that will be produced by the > KDF. >=20 > Need not? Please clarify what the purpose is here. It seems like > it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness? I suggest this wording: =E2=80=A6 There is no security benefit to using a ukm value that is longer than the key-encryption key that will be produced by the KDF. > S 2.2. > if ukm is provided, then salt =3D ukm, else salt =3D zero >=20 > zero in this case is "all zeros"? In any case, HKDF already > knows how to deal with salt not provided, to that would be > easier to specify. Good suggestion. This leads to two changes in the text: The ECC-CMS-SharedInfo structure optionally includes the ukm. If the ukm is present, the ukm is also used as the HKDF salt. HKDF uses an appropriate number of zero octets when no salt is provided. if ukm is provided, then salt =3D ukm, else salt is not provided PRK =3D HKDF-Extract(salt, K) KEK =3D HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), = SizeInOctets(KEK)) > S 8. > Don't forget to fill in these values. I assume you will do > so once IANA registers your code points? Correct. The IANA assignments are needed to fill in the values. > S 9. > This section is kinda diffident about whether the sender's > ephemeral is truly ephemeral. Is this a MUST? If so, please > say so. Section 2 already explains that the originator uses an ephemeral key = pair. > Appendix: > How many people have checked this ASN.1 module? At least two people have compiled it with different toolsets. > EDITORIAL > S 2. > Please put KEK in parentheses in your first use. In most places, it is spelled out. I added (KEK) to the first place, = and left it in the other places. > S 3. > It would be easier to put this above the key derivation stage. I followed the outline used in other specifications. I figures that the = implementers were fine with the previous outline. > Please provide some sort of reference or cross-reference for > =E2=80=9Ckari" The kari is defined in [CMS] as one of the choices in RecipientInfo. I = think that is clear from the sentence. > KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires > implementations to accept a KeyAgreeRecipientInfo SEQUENCE that > includes the ukm field. If present, the ukm is placed in the > entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. = The > ukm value need not be longer than the key-encryption key produced = by > the KDF. >=20 > This seems to be duplicated. Yes. I rewrote the text in Section 3.2 to point back to the earlier = text. > S 5. > This also seems to be largely duplicated. Can you refactor out > the common stuff. Because the content type is different, I think I already reduced it to = the minimum. Russ From nobody Sat May 6 14:35: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 1862D126B7F; Sat, 6 May 2017 14:35: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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149410650099.23151.9888425272428399151@ietfa.amsl.com> Date: Sat, 06 May 2017 14:35:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-05.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: Sat, 06 May 2017 21:35:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-05.txt Pages : 16 Date : 2017-05-06 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 6 14:36:05 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 8C293126B7F for ; Sat, 6 May 2017 14:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 L4Z3UJoBUsgK for ; Sat, 6 May 2017 14:36: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 241DD1200FC for ; Sat, 6 May 2017 14:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7BB383004FE for ; Sat, 6 May 2017 17:36: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 71ykbH0DAhPF for ; Sat, 6 May 2017 17:36:00 -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 2206F30024B; Sat, 6 May 2017 17:36:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <149410650099.23151.9888425272428399151@ietfa.amsl.com> Date: Sat, 6 May 2017 17:36:03 -0400 Cc: Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: References: <149410650099.23151.9888425272428399151@ietfa.amsl.com> To: curdle X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 21:36:04 -0000 This update resolves the comments from Eric Rescorla=E2=80=99s AD = Review. Russ > On May 6, 2017, at 5:35 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of the Elliptic Curve Diffie-Hellman Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-05.txt > Pages : 16 > Date : 2017-05-06 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and > curve448 in the Cryptographic Message Syntax (CMS). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun May 7 16:34:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752B412704A for ; Sun, 7 May 2017 16:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 qpERiCki4Prv for ; Sun, 7 May 2017 16:34:30 -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 1F7E0126DEE for ; Sun, 7 May 2017 16:34:30 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id x188so30265234itb.0 for ; Sun, 07 May 2017 16:34:30 -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=rm1TSKPYB3qwaRe5hNgIfJc4dFpssHeug6yI3k+ftdc=; b=C5p410axqEgFEFdTUkRzZvH4tdGQwhUravBUKalTBkrnVBK1SZw2o1dgCMVE9l6tf+ hsda33z541cuh3rgRW41k2OS6c8QGX+6IzXWEgjIHWw4tRBFcnvYCSmVz5BekMgClDfr jsKrJBkL20n7n3g9EhKlGtGJjM10zwO55Baf2g6Mj8qS1Fyvsrp7QgGDryBmmJis720b dEcA09/WITLgSYqz4LycP6atWSxO8z58tojTTzl82u2G2+SmZ7j0EK9kjGnFhIa41Ilx ECUI1CtVhmPIq09PxA+jS/nbFTKgm0whnPUEhLolNQiWsZM9wfZwH5IQOhKtIJ85xHD1 c40g== 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=rm1TSKPYB3qwaRe5hNgIfJc4dFpssHeug6yI3k+ftdc=; b=FVD6yHOrKufb3opplrRAq1C7fpfmjvVCXwQzX8JA+6hAaLvM8x/zfl30ozOymDqd91 C3d40dgORgNM9lwGwGmb4ioGWYkHXJTKqJldV1BuIpHf49HjI1Op3QB1EtsyymMDNyOh Ud8k6+TvtM0BzGAi/cxdu9Nz1ZRsHMm2As1PgntYXwafQ/1vFzJtmBXu04E/IUANYsIR TnmpO0IUDsU4vmd36nkXUu7Y6ytts2KspkN2109FvmnD1q0fJGkASfy5BKD3Lykifkss 1chcPOqRjGk6Tlpcl9glytpiNGGV41WED0RN5rF5WkIIzp3RRdOjRrMLYNX5Q0cZzCKT LyTA== X-Gm-Message-State: AN3rC/7A5dleoD33eNa6ZJvyrYM9069p9ShW7rq8G6FFyNWMmnuOQKRA xoWrhbHA9A/mmXI2iVkcVllvj9WyXvrQ X-Received: by 10.36.39.16 with SMTP id g16mr19342567ita.13.1494200069335; Sun, 07 May 2017 16:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Sun, 7 May 2017 16:34:28 -0700 (PDT) In-Reply-To: <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Sun, 7 May 2017 13:34:28 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 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: Sun, 07 May 2017 23:34:31 -0000 Jim Schaad wrote: > In particular, it is important for the spec to include v2 PKCS#8 examples > with the publicKey field, if such encoding is allowed. > > [JLS] This is a reasonable request. I will look at adding this as part of > the IETF last call comments. Here are four test vectors for Ed25519 PKCS#8 v2 keys (with the public key included) that I would like to have added to the RFC. PKCS#8 V2. The private key starts with a zero byte. -----BEGIN PRIVATE KEY----- 3053020101300506032b65700422042000b1a7c20b2b4ed9c78f3686db82 f854734cdc95be51def304d98e0cd30bf490a12303210063457cd4dfdd0e 98a53796265831d46ac6a5a685f2a54c9697a38b2c800d60ba -----END PRIVATE KEY----- PKCS#8 V2. The private key ends with a zero byte. -----BEGIN PRIVATE KEY----- 3053020101300506032b657004220420a22efdb713f0e1600d2a5ce948e3 21ca3a18137c47f15091a12c7126c1749a00a1230321001aeb8e3ee5ba5a fd91113466d19f4ea77fa0feffbd8c5adcb499927f12535f77 -----END PRIVATE KEY----- PKCS#8 V2. The public key starts with a zero byte. -----BEGIN PRIVATE KEY----- 3053020101300506032b6570042204202dc67de5186d9193021c0b104d9c 6ef24bee2bd395ccb5ed5a2db5f37a2fc1f0a12303210000c17e4d8bbff2 7c1fb618c23fce988703c7efa3cd590aacac12d3f1e3c90c8c -----END PRIVATE KEY----- PKCS#8 V2. The public key ends with a zero byte. -----BEGIN PRIVATE KEY----- 3053020101300506032b657004220420b2579f555a2eabdabac8d46997b1 c08fe8ce63858df124efc29c60dfbb86c349a1230321009d421270ce2fcc 08672c41e427214876245c9b0f14ab671b8bb9d266a492e400 -----END PRIVATE KEY----- Cheers, Brian From nobody Sun May 7 16:46: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 66A64126C83 for ; Sun, 7 May 2017 16:46:06 -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 H6VrApycqIBh for ; Sun, 7 May 2017 16:46:05 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD07126BF0 for ; Sun, 7 May 2017 16:46:05 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id k91so40968649ioi.1 for ; Sun, 07 May 2017 16:46:05 -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=QnInNA7pWKDgXbFQLVkHN5hppRAfogpXx4BOcuEu/wQ=; b=AMr1i/9pECuzvT4qe8wC4euKqH2BOLfLtiOud/2nNQn8St+pLvb5mmyfG/45mvJeMP YgWtKF6mU76UwxErf2b7LZOn5KgAiFA8SpvHab58K6icUi2+3fYJuvwdS709Q+3nn8j7 uhQEIdnYgFbZ0G2I7nMYZ3Zqe/Ab6Bm6GAC0yyFyEIklVALRJqrN//fnP4HMFMqlM+fY DciDy8iGbYpxxe7fXbvaY6U80gLO9NFXWxkNNmaqpzDgeTlHmUUb+oBMYoQucW7tbQ37 VW0MFhb6WnAVotIFvdOKTtz7nd3mzeghC2UK3Z04VsZ4763A9EbhlmLEKefGAtlVy/Ue C8NA== 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=QnInNA7pWKDgXbFQLVkHN5hppRAfogpXx4BOcuEu/wQ=; b=EglIOe7WZYnMb4uONbewguSu4sSo8ZmskvQilK+pE7E690OY5RGePBDCP8ZFwAUFrE +Dv4eua3Gctunw/2JlHa74sJPXfjQed3xznJjNq3wHQeYyucaLfA05kVy2e2xAoHG9/A fGvUWkBlow8EHgjGBSqpb/eeG+XBx7LnjOXi8dj9TfVDL7di7tsYr77iV1z3FVCDmrue nsC0h3RpOQKbs2KqZM6PGUewlsA1nHxHapDvJza7uI7mTSc4ZaEhQ29IMT9HfS9ORYgU znL7n/3qyf3XjlnaovJuQF5zDZGa6De6Cbj95luNubWzR5JBVhSj2spnqT/uzS/YfqRV V0qQ== X-Gm-Message-State: AODbwcAPX660ljhEZIXT6qiSseTUnPoDLkFL6hppBsHq42WlYqAqoAKW V77+59DbKCaU4yIf/Ac0VlbSpI+dVuVR X-Received: by 10.107.12.28 with SMTP id w28mr15212999ioi.209.1494200764528; Sun, 07 May 2017 16:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Sun, 7 May 2017 16:46:03 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Sun, 7 May 2017 13:46:03 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 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: Sun, 07 May 2017 23:46:06 -0000 Let me try again, this time using the same encoding that is used in the RFC (Base64): Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the public key included, that I'd like to have included in the RFC as test vectors. The first four examples are valid (I hope!) and 5th example is invalid. Ed25519 PKCS#8 v2. The first byte of the private key is zero: -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS MDIQBjRXzU390OmKU3liZYMdRqxqWmhfKlTJaXo4ssgA1gug== -----END PRIVATE KEY----- Ed25519 PKCS#8 v2. The last byte of the private key is zero: -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw== -----END PRIVATE KEY----- Ed25519 PKCS#8 v2. The first byte of the public key is zero: -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS MDIQAAwX5Ni7/yfB+2GMI/zpiHA8fvo81ZCqysEtPx48kMjA== -----END PRIVATE KEY----- Ed25519 PKCS#8 v2. The last byte of the public key is zero: -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS MDIQCdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLkAA== -----END PRIVATE KEY----- INVALID Ed25519 PKCS#8 v2. The last byte of the public key has had its high bit flipped. (In Ed25519 the high bit of the public key is not masked as in X25519.) -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS MDIQCdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLkgA== -----END PRIVATE KEY----- Cheers, Brian From nobody Sun May 7 18:01:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055531273E2 for ; Sun, 7 May 2017 18:01:31 -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 YnVzwrKd2xfP for ; Sun, 7 May 2017 18:01:28 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9984120227 for ; Sun, 7 May 2017 18:01:27 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 8so8125420ybw.1 for ; Sun, 07 May 2017 18:01: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; bh=l78x6PeHssdS6HT0pjKksXcaIV6TWYbjSi8shrSah50=; b=fZKy6HI/gnoGXiB3v7NhmORGTYt1x3N0FxTvCY9PnC4JQ6b0V3ugUkIO05U5hQU8Ct fXRQwOBeL+i+wASZyohDY0vpTjgeXUVfxWuOWz3yjneRMJHMzHVUkof3bvYxWKNlfvQ0 tBAn5X3iWYQevQvYglfVTfmJAKv5To4IHB187+gnV2MtIOwMgcQ7jWP8zeHMh1w6G8fU tFnQijjYMIByy4HwxaSP/0sLckxwjQLrNBs6wrCIf99oEpmjV4Ohg/NEmkQhd4u7DChc Fr6jTyJ4Czv7JxiAMYGM+BRcjIIerXg73Nu6n2wDBnjx8F4KS/nEjgNs2hx1rlng3vW0 RwSg== 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=l78x6PeHssdS6HT0pjKksXcaIV6TWYbjSi8shrSah50=; b=Pfm8SqIV17Hv/yd91CPxjzThZd3o0/EE8JO/APjmWB0IH22ExE4wtEUUnsudiEgGAF CA/soUdsKSTgoh7MnAaKGXGpOZGAganz6oPZE51XIrnb8vjotPWmTDWhwBKYCXeTCYLg hzK5f93/zQ8T9hDAxDNKuqEUFCcgGq/VOxf4MKZoyIQ2x6R2ZfuJjShjWpI2zjqQHnZt SSzxeIDeGr+Q7fvEyM2jVHEu+8WgcYkfMKcxbR/DCxxV8cM5QIKL9RTrlb/MlXyuXW4M 3QpogNEjRChKTNIg/EnCLzGK4EeOKby+Fgeq4zOysaeisE6F8Hf0lxEos39l3DQQCQV0 6/cw== X-Gm-Message-State: AODbwcBje74OvqnGWAF0CGVbv1JWWpymll1HIFeDIpgaxkqv91jYBoIr t7PgzN2w1RxZZGZkbex3deYx5lFu0Q== X-Received: by 10.37.44.69 with SMTP id s66mr8359365ybs.84.1494205286887; Sun, 07 May 2017 18:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Sun, 7 May 2017 18:01:26 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> <590B7E60.8000204@roumenpetrov.info> From: denis bider Date: Sun, 7 May 2017 19:01:26 -0600 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a1143210858b614054ef8c7b3 Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 08 May 2017 01:01:31 -0000 --001a1143210858b614054ef8c7b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roumen and I have exchanged details over the weekend. My understanding now is as follows. *Server-side situation:* OpenSSH versions before 7.5 (such as 7.3) send the "server-sig-algs" extension, but they only use it to indicate support for "rsa-sha2-512" and "rsa-sha2-256". They do not include other public key algorithms that the server supports, even though the server will accept those algorithms if they are attempted. It is intended that the server should send a complete set of accepted public key algorithms. My understanding is that OpenSSH versions 7.5 and later do this. Bitvise SSH Server has always sent a complete list. *Client-side situation:* There exist clients which have problems with OpenSSH 7.3 behavior, and clients that don't. *Clients with explicit public key configuration.* Bitvise SSH Client does not have a problem with this behavior, because it does not use public keys opportunistically. Our SSH Client will use a public key to authenticate only if the key is explicitly configured by the user. It will use only the requested key, and not other keys that it may find in various places of storage. As a result, our SSH Client has no use for a hint from the server about which key types are OK to use. It already knows the key it's going to use. The question is what signature algorithm (now renamed "public key algorithm") to use with that key. For this purpose, the information sent by OpenSSH is sufficient, regardless of version. For RSA keys, the "server-sig-algs" extension provides the info. For non-RSA keys, there's only one algorithm possible anyway, so we use it. *Clients with opportunistic key search.* Other SSH clients, including OpenSSH and PKIXSSH (Roumen's work) do not require a public key to be explicitly configured in order to be used. Such clients perform an opportunistic search, and try to use any and all keys that might work that can be found in various places of storage. This includes the user's .ssh directory, keys available via the SSH agent protocol, and keys specified on the command line. These types of clients have a problem, because: - In OpenSSH versions 7.5 and higher, the client can use the list of algorithms sent in the server's "server-sig-algs" extension to narrow down the public keys it's going to try. If the server doesn't list ECDSA or DSA, for example, the client can take that as authoritative, and can exclude those keys from authentication. This is nice because it may involve trying fewer keys. - In OpenSSH version 7.3, the server will only send "rsa-sha2-256" and "rsa-sha2-512", even if the server also accepts ECDSA and other algorithms. This means the client needs to have explicit treatment to detect the OpenSSH protocol version. If the OpenSSH version is older than 7.5, "server-sig-algs" can still be used to enable the use of "rsa-sha2-XXXX" instead of "ssh-rsa", but it cannot be used to exclude non-RSA keys in authentication. *Options:* *(A) Rename extension.* Roumen has requested that we rename the "server-sig-algs" extension and make it clear that the server must send all algorithms it will accept. I think this is not the best thing to do for the following reasons: - There are multiple implementations of this extension which are not impacted by the OpenSSH 7.3 issue. These implementations would suffer from the rename. - Implementations that are impacted by the OpenSSH 7.3 issue may still have a requirement to interoperate with OpenSSH 7.5, as well as other servers that currently send "server-sig-algs" with a complete list of algorithms. For such implementations, renaming the extension is again not a fix, but a further complication. *(B) Workaround by clients that need it.* My suggestion is that clients that use opportunistic key search, and wish to interoperate with OpenSSH 7.3, should implement a compatibility workaround for the way "server-sig-algs" is sent by that version. I think this is the better solution for the following reasons: - There are multiple implementations which are already not affected by the issue, whether communicating with OpenSSH or between themselves. In this case, those implementations do not need to change anything. - The work required for clients with opportunistic key search is similar to the work required in above option A), *assuming *those clients want to interoperate with OpenSSH 7.5+ and other existing servers that send "server-sig-algs" with a complete list of algorithms. In addition, it appears the draft needs to be clarified to state: - The server SHOULD send a complete list of public key algorithms it will accept for user authentication. - The client MAY authenticate with a public key algorithm not included in the server's list. At this time, I will make this update to the draft. denis On Fri, May 5, 2017 at 4:15 AM, denis bider wrote: > Talking to Roumen off-list to gain a better understanding of his > implementation, and why it has trouble dealing with "server-sig-algs" sen= t > by OpenSSH versions before 7.5. Our implementation does not have trouble. > His implementation might though, perhaps due to different combinations of > supported algorithms, and/or a different design approach. Trying to > understand this better. Will post when I do. > > On Fri, May 5, 2017 at 12:18 AM, denis bider > wrote: > >> Although my below response was self-explanatory, it is not sufficient. I= t >> requires elaboration: >> >> - The extension being specified is already deployed in a variety of >> implementations, not only OpenSSH. (See [1] at bottom) >> >> - Since the draft thus far remains compatible with existing >> implementations, changing the name of the extension would break >> compatibility. >> >> - Breaking compatibility with existing implementations requires a >> substantive reason. I am currently not aware of a substantive reason to = do >> this. >> >> - A problem in particular versions of a particular implementation is not >> a substantive reason. Idiosyncrasies of specific implementations are >> handled by others recognizing the SSH version string, not diverging the >> protocol. >> >> - It is not clear to me that the problem you reference in OpenSSH >> versions prior to 7.5 is a problem that needs to be addressed at this le= vel. >> >> - In a previous message, Damien Miller, who is representative of OpenSSH >> in this forum, has expressed a preference to keep the same extension nam= e. >> >> To be clear, the extension name is not one I'm overly happy with. In >> fact, I had changed the name of the extension from "server-sig-algs" to >> something more appropriate in an early version of the draft. However, by >> that time, another implementation already picked up "server-sig-algs". >> >> For this reason, I changed the spec back to "server-sig-algs". Although >> the name is not ideal, it is now in use; and the name being ideal is >> strictly less important than there being one identifier; and one identif= ier >> only; for the same concept, if reasonably possible. >> >> I stand by this decision, and think it's incorrect to modify the name at >> this time, unless the mechanics of the extension are changed in some way >> that's fundamental. >> >> [1] According to this excellent, but at this time slightly outdated >> comparison: >> >> http://ssh-comparison.quendi.de/comparison/hostkey.html >> >> ... implementations of rsa-sha2-*** public key algorithms include >> AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also supp= ort >> them, but this is not listed in the chart. This leads me to believe ther= e >> may be other implementations also. I know that at least three of these >> implementations also implement the "server-sig-algs" extension under its >> current name. >> >> >> On Thu, May 4, 2017 at 11:12 PM, denis bider >> wrote: >> >>> > 10x for new versions. >>> >>> You don't even have the decency to spell that. >>> >>> >>> > The name of extension "server-sig-algs" must be changed as well. >>> >>> No fucking way. Fuck off. >>> >>> >>> >>> On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F= =D0=B5=D1=82=D1=80=D0=BE=D0=B2 >>> wrote: >>> >>>> Hi denis, >>>> >>>> denis bider wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> in the interest of consensus, I have adopted the requested terminolog= y >>>>> changes in the two drafts. What was previously "signature algorithm" >>>>> is now >>>>> "public key algorithm", and what was previously "public key algorithm= " >>>>> is >>>>> now "public key format". >>>>> >>>>> Please review and let me know. >>>>> >>>> 10x for new versions. >>>> >>>> Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. >>>> I still think that chapter 4 IANA Considerations could be simplified t= o >>>> list only public key algorithm but this is not so important. >>>> The chapter refer to RFC4250 but section 7.1 Normative References lack >>>> reference to it. May be is good to list RFC4250 as well. >>>> No other remarks. >>>> >>>> >>>> >>>> About draft-ietf-curdle-ssh-ext-info-06.txt: >>>> The name of extension "server-sig-algs" must be changed as well. >>>> First because extension contain abbreviation of signature in name >>>> (description is fine), >>>> second because existing implementation does not follow rules from >>>> RFC4250, section 4.6.1. "Conventions for Names" and >>>> third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA >>>> signature methods were not being correctly advertised..." fixed in 7.5= . >>>> >>>> >>>> [SNIP] >>>> >>>> Regards, >>>> Roumen Petrov >>>> >>>> >>>> _______________________________________________ >>>> Curdle mailing list >>>> Curdle@ietf.org >>>> https://www.ietf.org/mailman/listinfo/curdle >>>> >>> >>> >> > --001a1143210858b614054ef8c7b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roumen and I have exchanged details over the weekend.= My understanding now is as follows.

Server-sid= e situation:

OpenSSH versions before 7.5 (such= as 7.3) send the "server-sig-algs" extension, but they only use = it to indicate support for "rsa-sha2-512" and "rsa-sha2-256&= quot;. They do not include other public key algorithms that the server supp= orts, even though the server will accept those algorithms if they are attem= pted.

It is intended that the server should send a= complete set of accepted public key algorithms. My understanding is that O= penSSH versions 7.5 and later do this. Bitvise SSH Server has always sent a= complete list.

Client-side situation:

There exist clients which have problems with OpenSSH 7= .3 behavior, and clients that don't.

Client= s with explicit public key configuration. Bitvise SSH Client does not h= ave a problem with this behavior, because it does not use public keys oppor= tunistically. Our SSH Client will use a public key to authenticate only if = the key is explicitly configured by the user. It will use only the requeste= d key, and not other keys that it may find in various places of storage.

As a result, our SSH Client has no use for a hint fr= om the server about which key types are OK to use. It already knows the key= it's going to use. The question is what signature algorithm (now renam= ed "public key algorithm") to use with that key. For this purpose= , the information sent by OpenSSH is sufficient, regardless of version. For= RSA keys, the "server-sig-algs" extension provides the info. For= non-RSA keys, there's only one algorithm possible anyway, so we use it= .

Clients with opportunistic key search.=C2= =A0Other SSH clients, including OpenSSH and PKIXSSH (Roumen's work) do = not require a public key to be explicitly configured in order to be used. S= uch clients perform an opportunistic search, and try to use any and all key= s that might work that can be found in various places of storage. This incl= udes the user's .ssh directory, keys available via the SSH agent protoc= ol, and keys specified on the command line.

These = types of clients have a problem, because:

- In Ope= nSSH versions 7.5 and higher, the client can use the list of algorithms sen= t in the server's "server-sig-algs" extension to narrow down = the public keys it's going to try. If the server doesn't list ECDSA= or DSA, for example, the client can take that as authoritative, and can ex= clude those keys from authentication. This is nice because it may involve t= rying fewer keys.

- In OpenSSH version 7.3, the se= rver will only send "rsa-sha2-256" and "rsa-sha2-512", = even if the server also accepts ECDSA and other algorithms. This means the = client needs to have explicit treatment to detect the OpenSSH protocol vers= ion. If the OpenSSH version is older than 7.5, "server-sig-algs" = can still be used to enable the use of "rsa-sha2-XXXX" instead of= "ssh-rsa", but it cannot be used to exclude non-RSA keys in auth= entication.

Options:

(A) Rename extension. Roumen has requested that we rename the &qu= ot;server-sig-algs" extension and make it clear that the server must s= end all algorithms it will accept.

I think this is= not the best thing to do for the following reasons:

- There are multiple implementations of this extension which are not imp= acted by the OpenSSH 7.3 issue. These implementations would suffer from the= rename.

- Implementations that are impacted by th= e OpenSSH 7.3 issue may still have a requirement to interoperate with OpenS= SH 7.5, as well as other servers that currently send "server-sig-algs&= quot; with a complete list of algorithms. For such implementations, renamin= g the extension is again not a fix, but a further complication.
<= br>
(B) Workaround by clients that need it.=C2=A0My sugges= tion is that clients that use opportunistic key search, and wish to interop= erate with OpenSSH 7.3, should implement a compatibility workaround for the= way "server-sig-algs" is sent by that version.

I think this is the better solution for the following reasons:

- There are multiple implementations which are already= not affected by the issue, whether communicating with OpenSSH or between t= hemselves. In this case, those implementations do not need to change anythi= ng.

- The work required for clients with opportuni= stic key search is similar to the work required in above option A), assu= ming=C2=A0those clients want to interoperate with OpenSSH 7.5+ and othe= r existing servers that send "server-sig-algs" with a complete li= st of algorithms.

In addition, it appears the draf= t needs to be clarified to state:

- The server SHO= ULD send a complete list of public key algorithms it will accept for user a= uthentication.

- The client MAY authenticate with = a public key algorithm not included in the server's list.
At this time, I will make this update to the draft.
<= br>
denis



=
On Fri, May 5, 2017 at 4:15 AM, denis bider <denisbider.ietf@gmail.com> wrote:
Talking to Roumen off-list to gain a better = understanding of his implementation, and why it has trouble dealing with &q= uot;server-sig-algs" sent by OpenSSH versions before 7.5. Our implemen= tation does not have trouble. His implementation might though, perhaps due = to different combinations of supported algorithms, and/or a different desig= n approach. Trying to understand this better. Will post when I do.=C2=A0

<= div class=3D"gmail_quote">On Fri, May 5, 2017 at 12:18 AM, denis bider <denisbider.ietf@gmail.com> wrote:
Although my below response was self-explanat= ory, it is not sufficient. It requires elaboration:

- Th= e extension being specified is already deployed in a variety of implementat= ions, not only OpenSSH. (See [1] at bottom)

- Sinc= e the draft thus far remains compatible with existing implementations, chan= ging the name of the extension would break compatibility.

- Breaking compatibility with existing implementations requires a s= ubstantive reason. I am currently not aware of a substantive reason to do t= his.

- A problem in particular versions of a parti= cular implementation is not a substantive reason. Idiosyncrasies of specifi= c implementations are handled by others recognizing the SSH version string,= not diverging the protocol.

- It is not clear to = me that the problem you reference in OpenSSH versions prior to 7.5 is a pro= blem that needs to be addressed at this level.

- I= n a previous message, Damien Miller, who is representative of OpenSSH in th= is forum, has expressed a preference to keep the same extension name.
=

To be clear, the extension name is not one I'm over= ly happy with. In fact, I had changed the name of the extension from "= server-sig-algs" to something more appropriate in an early version of = the draft. However, by that time, another implementation already picked up = "server-sig-algs".

For this reason, I ch= anged the spec back to "server-sig-algs". Although the name is no= t ideal, it is now in use; and the name being ideal is strictly less import= ant than there being one identifier; and one identifier only; for the same = concept, if reasonably possible.

I stand by this d= ecision, and think it's incorrect to modify the name at this time, unle= ss the mechanics of the extension are changed in some way that's fundam= ental.

[1] According to this excellent, but at thi= s time slightly outdated comparison:


... implementations of rsa-sha2-*** public key algorithms = include AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also= support them, but this is not listed in the chart. This leads me to believ= e there may be other implementations also. I know that at least three of th= ese implementations also implement the "server-sig-algs" extensio= n under its current name.


On Thu, May 4, 2017 at 11:12 PM= , denis bider <denisbider.ietf@gmail.com> wrote:
=
>=C2=A010x for new versions.

You don't= even have the decency to spell that.

<= br>
>=C2=A0The name of extension "server-sig-algs&qu= ot; must be changed as well.

No fucking way. Fuck off.



On Thu, May 4, 2017 at 1:17 PM, =D0=A0= =D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 <pki= xssh@roumenpetrov.info> wrote:
Hi denis,

denis bider wrote:
Hello everyone,

in the interest of consensus, I have adopted the requested terminology
changes in the two drafts. What was previously "signature algorithm&qu= ot; is now
"public key algorithm", and what was previously "public key = algorithm" is
now "public key format".

Please review and let me know.
 10x for new versions.

Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to lis= t only public key algorithm but this is not so important.
The chapter refer to RFC4250 but section 7.1 Normative References lack refe= rence to it. May be is good to list RFC4250 as well.
No other remarks.



About draft-ietf-curdle-ssh-ext-info-06.txt:
The name of extension "server-sig-algs" must be changed as well.<= br> First because extension contain=C2=A0 abbreviation of signature in name (de= scription is fine),
second because existing implementation does not follow rules from RFC4250, = section 4.6.1. "Conventions for Names" and
third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA sig= nature methods were not being correctly advertised..." fixed in 7.5.

[SNIP]

Regards,
Roumen Petrov


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




--001a1143210858b614054ef8c7b3-- From nobody Sun May 7 19:02:55 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD801292FC; Sun, 7 May 2017 19:02:53 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149420897339.23099.2218624537630142340@ietfa.amsl.com> Date: Sun, 07 May 2017 19:02:53 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-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, 08 May 2017 02:02:53 -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-07.txt Pages : 10 Date : 2017-05-07 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-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 Sun May 7 22:40: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 10557126DD9 for ; Sun, 7 May 2017 22:40:00 -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 r21WI6tujkBT for ; Sun, 7 May 2017 22:39:58 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA6E126CBF for ; Sun, 7 May 2017 22:39:58 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k91so43764047ioi.1 for ; Sun, 07 May 2017 22:39:58 -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=2vfxdI42epmKmfRN6uuCUBT55pjdRXdy3n07xnRV/JA=; b=ToR8tqLIDagxBvZYbi87o0qXLAveVYRZkBnNu3QNOf8uY2OfLnuTbytBIlHr6GNNW/ PK0OFqQ5BWgNDgVguga6MIIRlSvYFz0CcNzLFb3qgN/P0a4Yz9MvlR3D4jKmNfJJaP5T d+fgWt8HhOMe8sFezGbroWm2Q/1UlTsMgaJnwWjxSZiPvYMostZCKGl+zo8EcrxxCi4q hKeGvRGOZVSBI9OXoxJT11QSwGV5x7BpRccSlc1i9RYFwUFHKvDNzVo40yySEZDC7L+v +ront8mpQOgqMh23UkyK9YEmJ5xN4osadSxGyiZzqYBI4yMyMXrU5zCpKAyfS2VausnP iJ6g== 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=2vfxdI42epmKmfRN6uuCUBT55pjdRXdy3n07xnRV/JA=; b=FWMaJQ7Y4WY/1Gl/gdDOMWmCTemMZmgpeLLEe8FKejxRWSx5sHr4QLx98T4UPYruGa 0Y+GJKksLndgsOpf8t5+4Hp3EFE6sIERxPXggU7nU2tDK5EfJEmcBSqTzl3QwPVbmYef KH5wbIV/Zm1ryLpk1QxRndywo+DsUSFtu9MxxgvYkoDhwdrfFeBb05erm/s79A1Dq+8d uPubuekL+FDv7HR4HUsBcMypMLS1MvJi5aIq4z59G+UHL0OBZ++uJYG6fpgEdvPrWfpc W248adkcb+pNr9SsR5mKRo52pSyuQngGE21ShpNaC1aAXt/4hl1or3iMEs3iiI3qnoof 2JFw== X-Gm-Message-State: AN3rC/6cIfhqV0cg6byL1PIjdI/QPEXthGSSCU0IWhR79nDCT+kgu2nv 4nf6lYVHMEewkEQ0SvecwRi64Lnh6MEE X-Received: by 10.107.52.202 with SMTP id b193mr56221077ioa.150.1494221997724; Sun, 07 May 2017 22:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Sun, 7 May 2017 22:39:57 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Sun, 7 May 2017 19:39:57 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 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: Mon, 08 May 2017 05:40:00 -0000 On Sun, May 7, 2017 at 1:46 PM, Brian Smith wrote: > Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the public > key included, that I'd like to have included in the RFC as test > vectors. The first four examples are valid (I hope!) and 5th example > is invalid. Here are 4 pairs of example X25519 PKCS#8 v2 keys. The first key in each pair has its public key's high bit clear. The second key in each pair is the same except it has its public key's high bit set. The private key ends with a zero byte. The public key's high bit is zero. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA== -----END PRIVATE KEY----- The private key is the same as the previous one. The public key is also the same except its high bit is one. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswo4A== -----END PRIVATE KEY----- The private key starts with a zero byte. The public key's high bit is zero. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0YweBw== -----END PRIVATE KEY----- The private key is the same as the previous one. The public key is also the same except its high bit is one. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0Ywehw== -----END PRIVATE KEY----- The public key starts with a zero byte. The public key's high bit is zero. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/Dw== -----END PRIVATE KEY----- The private key is the same as the previous one. The public key is also the same except its high bit is one. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/jw== -----END PRIVATE KEY----- The public key ends with a zero byte, and thus its high bit is zero. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYAA== -----END PRIVATE KEY----- The private key is the same as the previous one. The public key is also the same except its high bit is one. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYgA== -----END PRIVATE KEY----- Cheers, Brian -- https://briansmith.org/ From nobody Mon May 8 01:39: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 0B43C126BF7 for ; Mon, 8 May 2017 01:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 D7hxIOYFvIn2 for ; Mon, 8 May 2017 01:39:00 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 879D4127B57 for ; Mon, 8 May 2017 01:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A5DB85FEC4 for ; Mon, 8 May 2017 11:38:58 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 02sDEcuEi41j for ; Mon, 8 May 2017 11:38:58 +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-smtp1.welho.com (Postfix) with ESMTPSA id 628F627F for ; Mon, 8 May 2017 11:38:58 +0300 (EEST) Date: Mon, 8 May 2017 11:38:57 +0300 From: Ilari Liusvaara To: curdle@ietf.org Message-ID: <20170508083857.GA6317@LK-Perkele-V2.elisa-laajakaista.fi> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.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] 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: Mon, 08 May 2017 08:39:03 -0000 On Sun, May 07, 2017 at 01:46:03PM -1000, Brian Smith wrote: > Let me try again, this time using the same encoding that is used in > the RFC (Base64): > > Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the public > key included, that I'd like to have included in the RFC as test > vectors. The first four examples are valid (I hope!) and 5th example > is invalid. In case you want these, I did the corresponding vectors for Ed448 (using the reference implementation). I also included example PKCS#8v1 and public key (hopefully these are correct, I do have TLS library capable of handling Ed448 keys, but it can't load this format, and writing key module code for it would be a bit nontrivial): Ed448 private key (from the first test vector in RFC8032): -----BEGIN PRIVATE KEY----- MEcCAQAwBQYDK2VxBDsEOWyCpWLLgI0Q1jK+ichRPr9skp803fqMn2PJlg7240ijUoyKP8wvBE45 o/xblEkvjwMudUmiAJj5Ww== -----END PRIVATE KEY----- Dumped as asn1: 0 30 71: SEQUENCE { 2 02 1: INTEGER 0 5 30 5: SEQUENCE { 7 06 3: OBJECT IDENTIFIER : EdDSA 448 signature algorithm { 1 3 101 113 } : } 12 04 59: OCTET STRING : 04 39 6C 82 A5 62 CB 80 8D 10 D6 32 BE 89 C8 51 : 3E BF 6C 92 9F 34 DD FA 8C 9F 63 C9 96 0E F6 E3 : 48 A3 52 8C 8A 3F CC 2F 04 4E 39 A3 FC 5B 94 49 : 2F 8F 03 2E 75 49 A2 00 98 F9 5B : } Note that the value of the private key is: 6C 82 A5 62 CB 80 8D 10 D6 32 BE 89 C8 51 3E BF 6C 92 9F 34 DD FA 8C 9F 63 C9 96 0E F6 E3 48 A3 52 8C 8A 3F CC 2F 04 4E 39 A3 FC 5B 94 49 2F 8F 03 2E 75 49 A2 00 98 F9 5B Ed448 public key (the first test vector in RFC8032): Public Key Information: Public Key Algorithm: EdDSA448 Algorithm Security Level: Ultra Public Key Usage: Public Key ID: 3a04967761a552db7e9e18c6dba4bd4aae119908 -----BEGIN PUBLIC KEY----- MEMwBQYDK2VxAzoAX9dEm1m0Yf0s54fsYWrUah2hNCSFpw4fig6nXYDpZ3jt8SR2m0bHBhvWeD3x 5Q9s0foavq/oJWGA -----END PUBLIC KEY----- Ed448 PKCS#8 v2. The first byte of the private key is zero: -----BEGIN PRIVATE KEY----- MIGFAgEBMAUGAytlcQQ7BDkAlY2VelwSNc5qN87ewXgVx3poDdR0OdqYyo/uBy4bnWEwDLG3dHXO p+usJ1j3LxKJXlLXuR1HeQahPAM6APhztQF4TM64dZqkG41k/xfFx8cD346La7OO3tdx1s7eWRnh /D+8vavt+fTgtDVtKgNq9hGF7z3YgA== -----END PRIVATE KEY----- Ed448 PKCS#8 v2. The last byte of the private key is zero: -----BEGIN PRIVATE KEY----- MIGFAgEBMAUGAytlcQQ7BDmB0i639YAUIxrkaJKyasoRPI/sVNywUPCC2G6LFgMH6u4K5aEaOH2m BQ4BPulPRikPE0RqH+M/yAChPAM6AO45hh9/sUCg4JD4SIOZmB4eBBemoVXmDp/U95GzOnE1oIgf TWQErk0VdzozIHu4AsIqup3RIZ7PAA== -----END PRIVATE KEY----- Ed448 PKCS#8 v2. The first byte of the public key is zero: -----BEGIN PRIVATE KEY----- MIGFAgEBMAUGAytlcQQ7BDn7w37WCHYkgzuWFxIp9s1UZdjBRWLCHQErJnYslwhzgarOZ4p5EnP5 JnC6y0q9FnZ/vaaqdgZSOVOhPAM6AAChrpHbZRZwBDZttZ5zgsK6WSL2jG+gOdwUITv0nOZ8wwv8 NTJ+CDurgoxzllC9o5V22p5f2LDKgA== -----END PRIVATE KEY----- Ed448 PKCS#8 v2. The last byte of the public key is zero: -----BEGIN PRIVATE KEY----- MIGFAgEBMAUGAytlcQQ7BDluPRT8xhEhgC+tSgkBXH/NcJ3rQcjQwuHuz4C3yoHa8dxx3rl5AoLs +Msa6yepMSM8szmmA3tDHhWhPAM6AAwjssedathfb9G4JZl44MHQrenIavuVLx7WGWlAyizxOICd OlNhiNnaG9X82sCHapbYur9B2M7aAA== -----END PRIVATE KEY----- INVALID Ed448 PKCS#8 v2. The last byte of the public key has had its high bit flipped. (In Ed448 the public key has an extra byte not present in X448.) -----BEGIN PRIVATE KEY----- MIGFAgEBMAUGAytlcQQ7BDmO9WySfQhRwpCdsECXiaxQAkMNe9QX2SApkWvjLMw07mXmtIFRWj0+ TblePrcgZtjcDVGCXfj+JgGhPAM6AFWgw4BsOzoCCGWud8wIhJnVVsxQXGqUPO+KySrQKzgR7Vnn r4JiAANv2azdo57L52bQB3wmjqLbAA== -----END PRIVATE KEY----- -Ilari From nobody Mon May 8 10:28: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 C4C15129535 for ; Mon, 8 May 2017 10:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksBiqx3lEX57 for ; Mon, 8 May 2017 10:28:02 -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 E15041292FC for ; Mon, 8 May 2017 10:28:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01D2C7E5.C3641500" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494264468; h=from:subject:to:date:message-id; bh=7b+Wc43txv+BQqVHxtmY0Oa8Nnow2by5e6UcViQstbU=; b=KnD/DFCQX5ag+0ZtSEJezyTANZlZDWDQ5g2DUgqXs3F/2wcScKxD/zbYf1gH9i+YaQcJwRMGzMC MAIVO8ZxfC7alzz0RoNIhtAlRJELtNakwizxNEgSPKnl7fGUKZxxmfYJa1cphqVGin/zBbaFeyY9z u+6K47+G6zuWQD5F8S4xVjnzHerl2y70G5iNlEmzTejW6neLXkJZMCAr7KRemODp0NDhiRmP6btrq KhfQ5wg0isj7QOjkR67382RjyJpvKjAP4cBIAvLxtmA3aSxkNa/ESdzottaEVMyZB2rmg3UHnzNvA JuMfO0f0eH7Zcy/AY5BAJ0MBeD/OAPCFiGvA== 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; Mon, 8 May 2017 10:27:47 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 10:27:35 -0700 From: Jim Schaad To: 'David Benjamin' , 'Brian Smith' CC: 'curdle' References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> In-Reply-To: Date: Mon, 8 May 2017 10:27:55 -0700 Message-ID: <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQdwJ1Iy/iAhSOZKsB1zCbUwIn5Ig/AcbaPPui/gCXwA== X-Originating-IP: [24.21.96.37] 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: Mon, 08 May 2017 17:28:05 -0000 ------=_NextPart_000_0071_01D2C7E5.C3641500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: David Benjamin [mailto:davidben@chromium.org]=20 Sent: Monday, May 1, 2017 9:15 AM To: Brian Smith ; Jim Schaad = Cc: curdle Subject: Re: [Curdle] FW: New Version Notification for = draft-ietf-curdle-pkix-04.txt =20 On Sun, Apr 30, 2017 at 8:17 PM Brian Smith > wrote: Jim Schaad > = wrote: > It is not always possible to detect corruption when you store in an = unencrypted form. What kind of corruption would we not be able to detect? It is possible that somehow the private key could get corrupted and that there could be a corresponding corruption to the public key such that they match again, but this seems extremely unlikely unless somebody simply replaced the key pair with another key pair. > It would also not be possible to know if it was the private key or the = public key that has been corrupted, just that the two values do not = match. This is the case with any kind of cryptographic check, including HMAC or whatnot. =20 (Not that it matters, but, to that end, would detecting corruption not = be just as easily served by stashing a checksum somewhere? If not = external to the serialization, there is already that attributes field.) =20 > > However, unless this is documented in the draft one way or > another as a MUST accept or a MUST NOT generate, I think > it will be an interop nightmare. In particular, we should avoid > the situation where some implementations produce v2 keys > so they can add the publicKey field, and where other > implementations reject v2 keys because they only parse v1, > where the publicKey field isn't allowed. > > I have not heard that this is an issue today with DH keys. This > makes me think that this is not going to be a big issue. I expect > that most implementations would all for parsing v2 keys even if > they then ignore the public key field. If that's the expectation then let's enshrine that in the spec by saying that implementations MUST accept v2 keys for these types of keys. In particular, I have seen PKCS#8 implementations that reject any v2 PKCS#8 file instead of ignoring the extra fields. =20 As the author of one such PKCS#8 implementation, I'd simply missed that = v2 PKCS#8 existed. Happy to add support (by way of ignoring the field = probably, yeah). Lacking any useful text about what to do, I interpreted = the version field to be analogous to RSAPrivateKey, another PKCS spec. = There, an RFC 2437 implementation that attempted to be = forwards-compatible (by accepting unknown versions and ignoring appended = fields) would have been confused come RFC 3447, which decided v1 meant a = semantically-incompatible otherPrimeInfos field. =20 RFC 5958 continues this. It does use ASN.1 extension markers, but X.680 = merely says "The action that is taken in each situation is determined by = the ASN.1 specifier", and RFC 5958 does not appear to say anything. =20 Is the intent that OneAsymmetricKey parsers accept a hypothetical v3 = with further appended fields, or should they reject those to allow for = RFC-3447-like changes? If so, how do they handle the version <=3D> extra = field correspondence? A numerical comparison? Assume all unknown values = are newer? The version number used in the ASN.1 tags corresponds to the = symbolic name of the version constants, rather than the numerical value, = so it's not obvious whether, say, defining v3(-1) would be acceptable. =20 [JLS] I had thought this was going to be an easy answer, but as I did = not have any of my ASN.1 documents with me last week I decided to defer = responding until I retrieved them from the backup drives. I am happy = that I did as what I thought was the correct answer isn=E2=80=99t. I = had always thought that the rules were that any additional fields could = be ignored by a prior parser when evaluating the content of the decoded = object. The answer from the X.680 is =E2=80=93 it depends. =20 =20 I guess that people are supposed to define what the correct behavior for = this is when they put the extensibility flag into an ASN.1 structure. = We did not do this when we wrote the document for OneSymmetricKey and we = should have done so. From what we were doing, I would say that the = answer is that all future fields can be ignored when parsing one of = these structures. This is the philosophy that was adopted for dealing = with unknown attributes. It would make sense to file an Errata to this = end on RFC 5958 so that we can make sure that this says the expected = method of doing thigs. =20 Jim =20 =20 David ------=_NextPart_000_0071_01D2C7E5.C3641500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = David Benjamin [mailto:davidben@chromium.org]
Sent: Monday, = May 1, 2017 9:15 AM
To: Brian Smith = <brian@briansmith.org>; Jim Schaad = <ietf@augustcellars.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] FW: New Version = Notification for draft-ietf-curdle-pkix-04.txt

 

On Sun, Apr 30, 2017 at 8:17 PM Brian Smith <brian@briansmith.org> = wrote:

Jim = Schaad <ietf@augustcellars.com> wrote:
> It is = not always possible to detect corruption when you store in an = unencrypted form.

What kind of corruption would we not be able to = detect? It is possible
that somehow the private key could get = corrupted and that there could
be a corresponding corruption to the = public key such that they match
again, but this seems extremely = unlikely unless somebody simply
replaced the key pair with another = key pair.

> It would also not be possible to know if it was = the private key or the public key that has been corrupted, just that the = two values do not match.

This is the case with any kind of = cryptographic check, including HMAC
or = whatnot.

 

(Not that it matters, but, to that end, would = detecting corruption not be just as easily served by stashing a checksum = somewhere? If not external to the serialization, there is already that = attributes field.)

 

> > = However, unless this is documented in the draft one way or
> = another as a MUST accept or a MUST NOT generate, I think
> it will = be an interop nightmare. In particular, we should avoid
> the = situation where some implementations produce v2 keys
> so they can = add the publicKey field, and where other
> implementations reject = v2 keys because they only parse v1,
> where the publicKey field = isn't allowed.
>
> I have not heard that this is an issue = today with DH keys.  This
> makes me think that this is not = going to be a big issue.  I expect
> that most = implementations would all for parsing v2 keys even if
> they then = ignore the public key field.

If that's the expectation then let's = enshrine that in the spec by
saying that implementations MUST accept = v2 keys for these types of
keys.

In particular, I have seen = PKCS#8 implementations that reject any v2
PKCS#8 file instead of = ignoring the extra fields.

 

As the author of one such PKCS#8 implementation, I'd = simply missed that v2 PKCS#8 existed. Happy to add support (by way of = ignoring the field probably, yeah). Lacking any useful text about what = to do, I interpreted the version field to be analogous to RSAPrivateKey, = another PKCS spec. There, an RFC 2437 implementation that attempted to = be forwards-compatible (by accepting unknown versions and ignoring = appended fields) would have been confused come RFC 3447, which = decided v1 meant a semantically-incompatible otherPrimeInfos = field.

 

RFC 5958 continues this. It does use ASN.1 extension = markers, but X.680 merely says "The action that is taken in each = situation is determined by the ASN.1 specifier", and RFC 5958 does = not appear to say anything.

 

Is the intent that OneAsymmetricKey parsers accept a = hypothetical v3 with further appended fields, or should they reject = those to allow for RFC-3447-like changes? If so, how do they handle the = version <=3D> extra field correspondence? A numerical comparison? = Assume all unknown values are newer? The version number used in the = ASN.1 tags corresponds to the symbolic name of the version constants, = rather than the numerical value, so it's not obvious whether, say, = defining v3(-1) would be acceptable.

 

[JLS] I had thought this was going to be an easy = answer, but as I did not have any of my ASN.1 documents with me last = week I decided to defer responding until I retrieved them from the = backup drives.=C2=A0 I am happy that I did as what I thought was the = correct answer isn=E2=80=99t.=C2=A0 I had always thought that the rules = were that any additional fields could be ignored by a prior parser when = evaluating the content of the decoded object.=C2=A0 The answer from the = X.680 is =E2=80=93 it depends.=C2=A0

 

I guess that people are = supposed to define what the correct behavior for this is when they put = the extensibility flag into an ASN.1 structure.=C2=A0 We did not do this = when we wrote the document for OneSymmetricKey and we should have done = so.=C2=A0 From what we were doing, I would say that the answer is that = all future fields can be ignored when parsing one of these = structures.=C2=A0 This is the philosophy that was adopted for dealing = with unknown attributes.=C2=A0 It would make sense to file an Errata to = this end on RFC 5958 so that we can make sure that this says the = expected method of doing thigs.

 

Jim

 

 

David

------=_NextPart_000_0071_01D2C7E5.C3641500-- From nobody Mon May 8 10:34: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 8EE28129557 for ; Mon, 8 May 2017 10:34:34 -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 BOPT3iYuG6Tx for ; Mon, 8 May 2017 10:34:32 -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 B69A3129553 for ; Mon, 8 May 2017 10:34: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=1494264870; h=from:subject:to:date:message-id; bh=DI0tMb2JWsQ/5T+mq4Sl9C4AzBQaWADH3sMVrcg0hUc=; b=ULWKfgHScX3QP0EFD49/q/LTeMjhhbNhWYSwMlycygNpP5v3wjvQLVXpGTl7Dr0NdBya8ZIlij4 RUAz6ilxkq0zSpUqVcCuO2aR6qFCMee8PPQTUGch8VTxx+S+KvyEXIPQRl2TvSqBsbAOjWr9PZC36 AfOEkFhSANP7iTGL4C4YfYXUdzUpTh77tNksZ9lVyKKTie/3QATnhmvzoq8X18WOMNJ2EEourPfje dEGUitXj3+xosc+x9MS4UE4HNQeAYIfbQjJcJf/AVy95teo+/9B6lzouN101VBVdvx6E2YEWkWJWY w8xX5pUP15DRe4EjUQoDSj3TgqW2L8nLDHKg== 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; Mon, 8 May 2017 10:34:30 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 10:34:18 -0700 From: Jim Schaad To: 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> In-Reply-To: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> Date: Mon, 8 May 2017 10:34:38 -0700 Message-ID: <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9Dmpp6H9l8iQ X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 17:34:35 -0000 I have written this document to make sure that the registration of the = donated arc is dealt with correctly in the future. I intend to ask EKR = to do an AD sponsorship of the document if people do not see any issues. = Please review the document to make sure it is correct in terms of = registrations that have been done in the past in this arc. Note that I have placed a reservation in the table to allow for a = subtree to be created at a future date. Jim -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, May 8, 2017 10:31 AM To: Jim Schaad ; Rick Andrews = ; Rick Andrews Subject: New Version Notification for = draft-schaad-curdle-oid-registry-00.txt A new version of I-D, draft-schaad-curdle-oid-registry-00.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-schaad-curdle-oid-registry Revision: 00 Title: Object Identifier Registry for the Curdle Working Group Document date: 2017-05-08 Group: Individual Submission Pages: 4 URL: = https://www.ietf.org/internet-drafts/draft-schaad-curdle-oid-registry-00.= txt Status: = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ Htmlized: = https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-curdle-oid-registry-00= Abstract: When the Curdle Security Working Group was chartered, a range of object identifiers was donated by Symantec Website Security for use by that working group. This document describes the range of identifiers that were assigned in that donated range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. = =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. The IETF Secretariat From nobody Mon May 8 10:50: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 50DF9126C23 for ; Mon, 8 May 2017 10:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 Esft52wH6fMH for ; Mon, 8 May 2017 10:50:46 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8F01267BB for ; Mon, 8 May 2017 10:50:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C65C621CF2; Mon, 8 May 2017 20:50:44 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id ZKBpSVYV8KLl; Mon, 8 May 2017 20:50:44 +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-smtp1.welho.com (Postfix) with ESMTPSA id 87BA228B; Mon, 8 May 2017 20:50:44 +0300 (EEST) Date: Mon, 8 May 2017 20:50:44 +0300 From: Ilari Liusvaara To: Jim Schaad Cc: 'curdle' Message-ID: <20170508175044.GA7584@LK-Perkele-V2.elisa-laajakaista.fi> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 17:50:48 -0000 On Mon, May 08, 2017 at 10:34:38AM -0700, Jim Schaad wrote: > I have written this document to make sure that the registration of the > donated arc is dealt with correctly in the future. I intend to ask > EKR to do an AD sponsorship of the document if people do not see any > issues. Please review the document to make sure it is correct in > terms of registrations that have been done in the past in this arc. I notice some possible issues: - The PKIX doc does not look to be valid reference for the 114 and 115 entries, since the PH variants were dropped out of it. - I presume 113 entry should be "id-EdDSA448", and not "id-EdDS448". - I presume 115 entry should be "id-EdDSA448-ph" and not "id-EdDS448=ph". > Note that I have placed a reservation in the table to allow for a > subtree to be created at a future date. I have seen two nested defined OIDs before. RFC5280 contains a pair of those (the anyEKU OID contains EKU extension OID as prefix)... -Ilari From nobody Mon May 8 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 2B22F128AFE for ; Mon, 8 May 2017 11:03:59 -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 cNmwfI1BKZCR for ; Mon, 8 May 2017 11:03:58 -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 17008128656 for ; Mon, 8 May 2017 11:03:58 -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=1494266634; h=from:subject:to:date:message-id; bh=IvSY67xqIoc/YVJB1hcbYNCSbpQhd9C5VFxW05Ct/sU=; b=h++4XjkgEfxZCMyDrK0aavlMs6EpKTQ3tyt3vnHj3wwSz7zfsZste8VpUeW3G4Yoa6ctnmEL4T5 5mz5QJqQb5CBsdrKtvNNA1R0k/Jb6x4EJl2glwaLemnx4zXe0jFQWDuHvBCdVfOUmRbMvcvzUbMIS 9kVTIIJaTJfjnYl+74+sPRK+2wBG3jWjSw5Q7EE8YNIwElLcHUJAzE/663E4qjGPoUdHIW5S8DlDf 1Fgks9KjoFpGiV7DWtZmC/iiZSjC4yZI1j9mrRujFNpcPf65CAifT0nN1tWceYVoEts3BEU/gjojh 2Yaa5JD9NpUAFjuIKPi+/BjvTwK9hV42HY9g== 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; Mon, 8 May 2017 11:03:54 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 11:03:42 -0700 From: Jim Schaad To: CC: 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170508175044.GA7584@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170508175044.GA7584@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 8 May 2017 11:04:02 -0700 Message-ID: <007e01d2c825$7b2c6d60$71854820$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAcg/Po+h3ad+YA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:03:59 -0000 -----Original Message----- From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]=20 Sent: Monday, May 8, 2017 10:51 AM To: Jim Schaad Cc: 'curdle' Subject: Re: [Curdle] FW: New Version Notification for = draft-schaad-curdle-oid-registry-00.txt On Mon, May 08, 2017 at 10:34:38AM -0700, Jim Schaad wrote: > I have written this document to make sure that the registration of the = > donated arc is dealt with correctly in the future. I intend to ask=20 > EKR to do an AD sponsorship of the document if people do not see any=20 > issues. Please review the document to make sure it is correct in=20 > terms of registrations that have been done in the past in this arc. I notice some possible issues: - The PKIX doc does not look to be valid reference for the 114 and 115 entries, since the PH variants were dropped out of it. - I presume 113 entry should be "id-EdDSA448", and not "id-EdDS448". - I presume 115 entry should be "id-EdDSA448-ph" and not "id-EdDS448=3Dph". [JLS] Yes - I am missing the A in this. > Note that I have placed a reservation in the table to allow for a=20 > subtree to be created at a future date. I have seen two nested defined OIDs before. RFC5280 contains a pair of = those (the anyEKU OID contains EKU extension OID as prefix)... [JLS] This is not meant to be a nested OID, just the ability to define = 1.3.101.100.1 and so forth. Jim -Ilari From nobody Mon May 8 11:06: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 F210F128AFE for ; Mon, 8 May 2017 11:06:30 -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 W3o1pCck--ju for ; Mon, 8 May 2017 11:06:29 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 14083128656 for ; Mon, 8 May 2017 11:06:29 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id m17so7533181pfg.3 for ; Mon, 08 May 2017 11:06:29 -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=tCwqXulTl75dFNSeFC8u2C9Ly45SHxhh7FuA4BqOu6k=; b=Vj952ujP5niAhpmSSARyKdgsALG9uQLprit8/xzXE+Eav52yDD9KGFF6AbcS/bffHh KGTHlr6HRCB0TnJt25kiQp1NAA3fwHTBxhvYKtQ46Vtktm83ZsfobAu0b3i2xKKd3r0H ZU8EKKjpujPBKqj3Sw9/ZqFtPqfioU7Qyg5/8= 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=tCwqXulTl75dFNSeFC8u2C9Ly45SHxhh7FuA4BqOu6k=; b=iOEteuQnVAVAqpVwwvld8eX8dSKfihSb0DMIAI8o6ZxBAV+QRSkv5EH93X7EWLLYgE 1Berf6XtBpj2Sbu6iP+iHh47enF9ANRZ7Z3XSjdugPlNEQ41sofYZDwDVoN/eHHRmJXJ PqbmgaQO2qeR4PWL4zFr1XwkBiJv8oyI2c25gsFfxUKFRHuVOD3ZgXEgx3cdbrQb+etj L5Pc8cdwyehscDPw4NPE9r4+rZYrh3Ok4EYJg8i2FZl3y+xug9ckr2IsZaE0RYHIvTN8 PItsWM1Me3GAPseD2LRWFDDq6vlqU1o+dS7i6CKi0Dg08HnkEEx6nl1HlGvdiOgoN/uu lQoA== X-Gm-Message-State: AN3rC/514rZWIehvZLR7DHVAHVosm4cyQnpJkx36gVlQ6WVJffWcK0sl pTARDbg16MnjqsD5qLuQy4R9/QkuMgTFeOQ= X-Received: by 10.98.82.77 with SMTP id g74mr20144257pfb.115.1494266788376; Mon, 08 May 2017 11:06:28 -0700 (PDT) MIME-Version: 1.0 References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> In-Reply-To: <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> From: David Benjamin Date: Mon, 08 May 2017 18:06:16 +0000 Message-ID: To: Jim Schaad , Brian Smith Cc: curdle Content-Type: multipart/alternative; boundary=94eb2c035af01fb1f3054f071974 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: Mon, 08 May 2017 18:06:31 -0000 --94eb2c035af01fb1f3054f071974 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 8, 2017 at 1:27 PM Jim Schaad wrote: > *From:* David Benjamin [mailto:davidben@chromium.org] > > *Sent:* Monday, May 1, 2017 9:15 AM > *To:* Brian Smith ; Jim Schaad < > ietf@augustcellars.com> > > > *Cc:* curdle > *Subject:* Re: [Curdle] FW: New Version Notification for > draft-ietf-curdle-pkix-04.txt > > > > On Sun, Apr 30, 2017 at 8:17 PM Brian Smith wrote: > > In particular, I have seen PKCS#8 implementations that reject any v2 > PKCS#8 file instead of ignoring the extra fields. > > > > As the author of one such PKCS#8 implementation, I'd simply missed that v= 2 > PKCS#8 existed. Happy to add support (by way of ignoring the field > probably, yeah). Lacking any useful text about what to do, I interpreted > the version field to be analogous to RSAPrivateKey, another PKCS spec. > There, an RFC 2437 implementation that attempted to be forwards-compatibl= e > (by accepting unknown versions and ignoring appended fields) would have > been confused come RFC 3447, which decided v1 meant a > semantically-incompatible otherPrimeInfos field. > > > > RFC 5958 continues this. It does use ASN.1 extension markers, but X.680 > merely says "The action that is taken in each situation is determined by > the ASN.1 specifier", and RFC 5958 does not appear to say anything. > > > > Is the intent that OneAsymmetricKey parsers accept a hypothetical v3 with > further appended fields, or should they reject those to allow for > RFC-3447-like changes? If so, how do they handle the version <=3D> extra > field correspondence? A numerical comparison? Assume all unknown values a= re > newer? The version number used in the ASN.1 tags corresponds to the > symbolic name of the version constants, rather than the numerical value, = so > it's not obvious whether, say, defining v3(-1) would be acceptable. > > > > [JLS] I had thought this was going to be an easy answer, but as I did not > have any of my ASN.1 documents with me last week I decided to defer > responding until I retrieved them from the backup drives. I am happy tha= t > I did as what I thought was the correct answer isn=E2=80=99t. I had alwa= ys thought > that the rules were that any additional fields could be ignored by a prio= r > parser when evaluating the content of the decoded object. The answer fro= m > the X.680 is =E2=80=93 it depends. > > > > I guess that people are supposed to define what the correct behavior for > this is when they put the extensibility flag into an ASN.1 structure. We > did not do this when we wrote the document for OneSymmetricKey and we > should have done so. From what we were doing, I would say that the answe= r > is that all future fields can be ignored when parsing one of these > structures. This is the philosophy that was adopted for dealing with > unknown attributes. It would make sense to file an Errata to this end on > RFC 5958 so that we can make sure that this says the expected method of > doing thigs. > That works for me. What would you then say is the intended interpretation of the version field? Going from PrivateKeyInfo to OneAsymmetricKey makes sense to bump the version because it is arguably a semi-incompatible change. (And, regardless, it's too late to undo that.) I would maybe argue that future versions of OneAsymmetricKey should *not* bump the version number. It's not clear to me it serves any purpose in this context since a parser can't do anything useful with unknown values. So perhaps: - When serializing without publicKey, serializing code SHOULD use v1 (PrivateKeyInfo). v2 (OneAsymmetricKey) would also work, but this will be less compatible. - When serializing with publicKey, serializing code MUST use v2, - When parsing and the version is v1, parse as PrivateKeyInfo (i.e. non-extensible and publicKey does not exist). - When parsing and the version is v2, parse as OneAsymmetricKey. When parsing as OneAsymmetricKey, one MUST ignore trailing fields after the OPTIONAL publicKey. - When parsing and the version is anything else, reject. This is some invalid thing. I'm also equally fine with some variant of Brian's stricter interpretation, which effectively means removing the X.680 extensibility markers. I don't think this is a context where extensibility is needed and, regardless, we've already got that attributes field. (OneAsymmetricKey itself could probably have been skipped in favor of defining a publicKey attribute.) David --94eb2c035af01fb1f3054f071974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 8,= 2017 at 1:27 PM Jim Schaad <ietf@augustcellars.com> wrote:

From: David Benjamin [mailto:davidben@chromium.org]

= Sent: Monday, May 1, 2017 9:15 AM
To: Brian Smith <brian@briansmith.org<= /a>>; Jim Schaad <ietf@augustcellars.com>


Cc: curdle <<= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">curdle@ietf.org>=
Subject: Re: [Curdle] FW: New Version Notification for draft-iet= f-curdle-pkix-04.txt

<= /u>=C2=A0

On Sun, Apr 30, 2= 017 at 8:17 PM Brian Smith <brian@briansmith.org> wrote:

In particula= r, I have seen PKCS#8 implementations that reject any v2
PKCS#8 file ins= tead of ignoring the extra fields.

=C2=A0

As the author of one such PKCS#8 implementation, I'd simply missed tha= t v2 PKCS#8 existed. Happy to add support (by way of ignoring the field pro= bably, yeah). Lacking any useful text about what to do, I interpreted the v= ersion field to be analogous to RSAPrivateKey, another PKCS spec. There, an= RFC 2437 implementation that attempted to be forwards-compatible (by accep= ting unknown versions and ignoring appended fields) would have been confuse= d come RFC=C2=A03447, which decided v1 meant a semantically-incompatible ot= herPrimeInfos field.

= =C2=A0

RFC 5958 contin= ues this. It does use ASN.1 extension markers, but X.680 merely says "= The action that is taken in each situation is determined by the ASN.1 speci= fier", and RFC 5958 does not appear to say anything.

=

=C2=A0

<= div>

Is the intent that OneAsymmetricKey parsers acce= pt a hypothetical v3 with further appended fields, or should they reject th= ose to allow for RFC-3447-like changes? If so, how do they handle the versi= on <=3D> extra field correspondence? A numerical comparison? Assume a= ll unknown values are newer? The version number used in the ASN.1 tags corr= esponds to the symbolic name of the version constants, rather than the nume= rical value, so it's not obvious whether, say, defining v3(-1) would be= acceptable.

=C2=A0

[JLS] I had thought = this was going to be an easy answer, but as I did not have any of my ASN.1 = documents with me last week I decided to defer responding until I retrieved= them from the backup drives.=C2=A0 I am happy that I did as what I thought= was the correct answer isn=E2=80=99t.=C2=A0 I had always thought that the = rules were that any additional fields could be ignored by a prior parser wh= en evaluating the content of the decoded object.=C2=A0 The answer from the = X.680 is =E2=80=93 it depends.=C2=A0

=C2=A0

I guess that people are su= pposed to define what the correct behavior for this is when they put the ex= tensibility flag into an ASN.1 structure.=C2=A0 We did not do this when we = wrote the document for OneSymmetricKey and we should have done so.=C2=A0 Fr= om what we were doing, I would say that the answer is that all future field= s can be ignored when parsing one of these structures.=C2=A0 This is the ph= ilosophy that was adopted for dealing with unknown attributes.=C2=A0 It wou= ld make sense to file an Errata to this end on RFC 5958 so that we can make= sure that this says the expected method of doing thigs.


That works for me. What would you then say is the intended inte= rpretation of the version field? Going from PrivateKeyInfo to OneAsymmetric= Key makes sense to bump the version because it is arguably a semi-incompati= ble change. (And, regardless, it's too late to undo that.) I would mayb= e argue that future versions of OneAsymmetricKey should *not* bump the vers= ion number. It's not clear to me it serves any purpose in this context = since a parser can't do anything useful with unknown values. So perhaps= :

- When serializing without publicKey, serializin= g code SHOULD use v1 (PrivateKeyInfo). v2 (OneAsymmetricKey) would also wor= k, but this will be less compatible.
- When serializing with publ= icKey, serializing code MUST use v2,
- When parsing and the versi= on is v1, parse as PrivateKeyInfo (i.e. non-extensible and publicKey does n= ot exist).
- When parsing and the version is v2, parse as OneAsym= metricKey. When parsing as OneAsymmetricKey, one MUST ignore trailing field= s after the OPTIONAL publicKey.
- When parsing and the version is= anything else, reject. This is some invalid thing.

I'm also equally fine with some variant of Brian's stricter inter= pretation, which effectively means removing the X.680 extensibility markers= . I don't think this is a context where extensibility is needed and, re= gardless, we've already got that attributes field. (OneAsymmetricKey it= self could probably have been skipped in favor of defining a publicKey attr= ibute.)

David
--94eb2c035af01fb1f3054f071974-- From nobody Mon May 8 11:10: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 4025E128AFE for ; Mon, 8 May 2017 11:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQkejsm87zCX for ; Mon, 8 May 2017 11:10:53 -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 C9011128B8E for ; Mon, 8 May 2017 11:10:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01D2C7EB.C651D760" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494267050; h=from:subject:to:date:message-id; bh=96jg8YmgWrC5ch3rWbaQo78AGukTl3hB427gm6JFjJU=; b=ZACFZWueNjaM2juya1m1I6HjjT43tG3ebO1LG8VBmgffMuLRRyUCEHU3zynfMIKiQP8uPGyBKbs zVZ6yRXGdh35Tk4ezclbh98T0763YWlp6O0Aj7/6TLhroL39OD/Vt4ytOLwGAvOn0cNedyf+3OEaA UsSzGwJR9SIx3eGjaFE3uU1PWlFINfo9pGU+ps1IkcLxg8+ctKoyBFceJdb+csfjO3lFvDr1qhMS6 V8f+Ul7178WyvQ8b00PkqYr/6bs8FY+90oQ1e3aJGvHqWZZsbVHlu9rwPqrUIQ5xrCQSVnAssV7Xh mzmBJW58lLhoZJX+AOtuQEvzQcTJA00UgV3A== 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; Mon, 8 May 2017 11:10:50 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 11:10:37 -0700 From: Jim Schaad To: 'Eric Rescorla' , 'curdle' References: In-Reply-To: Date: Mon, 8 May 2017 11:10:57 -0700 Message-ID: <007f01d2c826$72af9df0$580ed9d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHbQntJtMtoRE13Ns+MdJ1uAlEKgaHZv7bA X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] AD Review: 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: Mon, 08 May 2017 18:10:55 -0000 ------=_NextPart_000_0080_01D2C7EB.C651D760 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see in-line =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, May 5, 2017 12:46 PM To: curdle Subject: [Curdle] AD Review: draft-ietf-curdle-pkix-04.txt =20 AD Review: draft-ietf-curdle-pkix-04.txt =20 TECHNICAL I see that Brian Smith made a number of comments on 4/29. Is the WG convinced that they have addressed them adequately. =20 [JLS] I believe that he is probably not happy with the resolution = dealing with the requirement to make all of the private keys use either = only v1 or v2, however I think that the working group has reached a = rough consensus on not making either of these a MUST. =20 =20 I need to go through the examples dealing with v2 and erroneous keys = that have been supplied, but intend to incorporate them into the = document. =20 S 5. The RFC5280 text on {encipher,decipher}Only is kind of obscure. Say that I have keyAgreement | encipherOnly, can I use this key for TLS? =20 one of the following MAY also be present: =20 Am I supposed to read from this that no other extension may be present? I think this should be explicitly stated. The same applies to signature certificates. =20 Also, did the WG discuss whether you should mandate keyUsage? =20 [JLS] There was no discussion that I remember about the question of = mandating the keyUsage extension. This would end up being deferred to = RFC 5280 =E2=80=93 so that answer would be no. =20 I am not sure that this is the correct document to deal with the meaning = of the {encipher,decipher}Only bits in key usage. I cannot remember = ever having seen these in practice, unlike the non-Repudiation bit. If = memory serves, I was once told that these bits made more sense for the = Royal Holloway than they do for DH or ECDH. My personal opinion would = be that if you set either of those bits, then the certificate would not = be usable for TLS. (I believe that the question is academic for TLS 1.3 = since key agreement certificates are not used anywhere.) The use of the = bits would be for the purpose of doing some type of an authenticated key = transport algorithm where the algorithms would be ECDH+HKDF+AES-GCM as a = single identified item. =20 =20 EDITORIAL S 1. HashEdDSA mode with pre-hashing. The convention used for identifying the algorithm/curve combinations are to use the Ed25519 and Ed448 for =20 convention is =20 RFC 7748 seems to use "curveXXX" rather than "CurveXXX" =20 [JLS] fixed locally =20 S 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 know what you mean by "even number" but I think it would be clearer to say "an exact multiple of 8 bits" so people don't think you are talking about the parity of the number of bytes. =20 [JLS] Take makes it clearer =E2=80=93 done. =20 S 13. Diffie-Hellman has two ls =20 [JLS] Done =20 Jim =20 =20 -Ekr =20 =20 ------=_NextPart_000_0080_01D2C7EB.C651D760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please see = in-line

 

From: = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Friday, May 5, 2017 12:46 PM
To: = curdle <curdle@ietf.org>
Subject: [Curdle] AD Review: = draft-ietf-curdle-pkix-04.txt

 

AD = Review: draft-ietf-curdle-pkix-04.txt

 

TECHNICAL

I see that Brian Smith made a number of comments on = 4/29. Is the WG

convinced = that they have addressed them adequately.

 

[JLS] I believe that he is probably not happy = with the resolution dealing with the requirement to make all of the = private keys use either only v1 or v2, however I think that the working = group has reached a rough consensus on not making either of these a = MUST.=C2=A0=C2=A0

 

I need to go through the = examples dealing with v2 and erroneous keys that have been supplied, but = intend to incorporate them into the = document.

 

S = 5.

The RFC5280 text on = {encipher,decipher}Only is kind of obscure.

Say that I have keyAgreement | encipherOnly, can I use = this key

for = TLS?

 

   one of the following MAY also be = present:

 

Am I supposed to read from this that no other = extension may be

present? = I think this should be explicitly stated. The = same

applies to signature = certificates.

 

Also, did the WG discuss whether you should mandate = keyUsage?

 

[JLS] There was no = discussion that I remember about the question of mandating the keyUsage = extension.=C2=A0 This would end up being deferred to RFC 5280 =E2=80=93 = so that answer would be no.

 

I am not sure that this = is the correct document to deal with the meaning of the = {encipher,decipher}Only bits in key usage.=C2=A0 I cannot remember ever = having seen these in practice, unlike the non-Repudiation bit.=C2=A0 If = memory serves, I was once told that these bits made more sense for the = Royal Holloway than they do for DH or ECDH.=C2=A0 My =C2=A0personal = opinion would be that if you set either of those bits, then the = certificate would not be usable for TLS.=C2=A0 (I believe that the = question is academic for TLS 1.3 since key agreement certificates are = not used anywhere.)=C2=A0 The use of the bits would be for the purpose = of doing some type of an authenticated key transport algorithm where the = algorithms would be ECDH+HKDF+AES-GCM as a single identified = item.

 

 

EDITORIAL

S 1.

   HashEdDSA mode with pre-hashing.  = The convention used for identifying

   the algorithm/curve combinations are to = use the Ed25519 and Ed448 for

 

convention is

 

RFC 7748 seems to use "curveXXX" rather than = "CurveXXX"

 

[JLS] fixed = locally

 

S = 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 = know what you mean by "even number" but I think it would be = clearer

to say "an = exact multiple of 8 bits" so people don't think you = are

talking about the = parity of the number of bytes.

 

[JLS] Take makes it clearer =E2=80=93 = done.

 

S = 13.

Diffie-Hellman has two = ls

 

[JLS] = Done

 

Jim

 

 

-Ekr

 

 

------=_NextPart_000_0080_01D2C7EB.C651D760-- From nobody Mon May 8 11:42: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 29F7D1294A8 for ; Mon, 8 May 2017 11:42:49 -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 tNgnq-nOTDoy for ; Mon, 8 May 2017 11:42:47 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 6D8D2128B51 for ; Mon, 8 May 2017 11:42:47 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id p24so56252942ioi.0 for ; Mon, 08 May 2017 11:42:47 -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=9EANgNjRevOcmZBivph7nEYyZyJhHbhRZdfEQNBLzaI=; b=ik/5/GHsrDGYYxa8wjq3B4gK2AvkO89V4jHsobgJWOnNGTibXT0pBAt+HnGZA4SbQi j2eMCH7jxFa0vyQIl9AkVIRF3UmpGnmo+UPGJChvFncAJtIgtWiozxHPeaFM0JfHYHQI gA6CmyMBHMZh3Q8G+odJbQ8vZN+vNh59BPKghFSs2CCmaN54yzfmLxt4vWz93xeLWcQd nZI83zL5ZzdogpZbjmG0J4u+FyeOJEEu/zDnvbI66armWO21ARf5i5F3l4nVH/+49gDi UEiELl7KN0Thj1dTbXsbJNsYp4EZVZvDZPfT2lM0+P7lVi+tteLE5JZMXkPcyn7p8HZq WHqg== 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=9EANgNjRevOcmZBivph7nEYyZyJhHbhRZdfEQNBLzaI=; b=eiTKoSbI003zqD6OxKjXi73dAS4JVqEpZPP7AsTqwh9qsjyq5UTHSorxs5I/lzGWBo TfK+UymWKbTPQAouHflbL/pdulzmQgqA+y7OxM2kJP5A/WeHw1t3LlvX+AeANHJVQ5Jm QSQiYtBMITzG4qfDZQAJba+0FHLUhG/jIT16BJyDjyfv1dTnr04X2NIRxMtbPm1OTq8w buI0nd3FiEkySBBaP1ps0YgB9aeGuPRQwS0XrXNQGZhOHvYN0qbj7W8JcTfSDjVZthd7 fHqxckjpvFauAikCYaRv+2Rvqjt45LZ9WXzBFtubOKPaGAMaDDcHWGEmqoNB8bG4Isnx BRBA== X-Gm-Message-State: AODbwcBuJYRPgjIw7nSS8bCV/Y2QluLIixfp9uO1DoPn/uiPYULVknnf i+tWiehJ4ByJ4wMwatfuu1S0NSR5ccap X-Received: by 10.107.12.28 with SMTP id w28mr18731528ioi.209.1494268966639; Mon, 08 May 2017 11:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Mon, 8 May 2017 11:42:45 -0700 (PDT) In-Reply-To: <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> From: Brian Smith Date: Mon, 8 May 2017 08:42:45 -1000 Message-ID: To: Jim Schaad Cc: David Benjamin , curdle Content-Type: text/plain; charset=UTF-8 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: Mon, 08 May 2017 18:42:49 -0000 Jim Schaad wrote: > David Benjamin wrote: >> RFC 5958 continues this. It does use ASN.1 extension markers, but X.680 >> merely says "The action that is taken in each situation is determined by the >> ASN.1 specifier", and RFC 5958 does not appear to say anything. > I guess that people are supposed to define what the correct behavior for > this is when they put the extensibility flag into an ASN.1 structure. We > did not do this when we wrote the document for OneSymmetricKey and we should > have done so. From what we were doing, I would say that the answer is that > all future fields can be ignored when parsing one of these structures. This > is the philosophy that was adopted for dealing with unknown attributes. It > would make sense to file an Errata to this end on RFC 5958 so that we can > make sure that this says the expected method of doing thigs. I would rather it not use the extensibility feature of ASN.1. My understanding is that if one doesn't use the extensibility feature, then "dumb" parsers like mine and the one in BoringSSL work fine. Once you start using the extensibility feature, creating a correct parser becomes more difficult. And we don't need the flexibility anyway, since PKCS#8 v1 already defined an extensibility mechanism (attributes). That is, we shouldn't have a v2 at all, nor the publicKey field, but instead should have used attributes. Whatever we do with v2 and publicKey now is about coping with the fact that v2 is already defined. Going forward, extensibility should be handled with attributes, so I expect no new versions to be defined. Cheers, Brian -- https://briansmith.org/ From nobody Mon May 8 11:46: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 134251294A8 for ; Mon, 8 May 2017 11:46:20 -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 Dt8ctQVM3FIu for ; Mon, 8 May 2017 11:46:18 -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 7D933128B51 for ; Mon, 8 May 2017 11:46:18 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id o5so72665708ith.1 for ; Mon, 08 May 2017 11:46:18 -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=ELbTtjDPPzz1LSUINCP/snN9sXJIkyQH8uWcUB3SXGE=; b=RM/JVr0jkzYOs1EaS8V7dTnVpjqZg0K7zLHKL/EB+F/WYt8PYj0TiH0atHwL72rmRY ww/NiBydwrjXsSN3JsxPKT9imHDbeVOyjkG+ApbQWXv4RYkI/rNZrpVbvHPGkgYRMija ZgvBqxwepG//28HKuH4NA/YUwCLnl/4gu65mq+BsRBz68ry9Aei0HAy8xoy5xFGqTX/I k9HJvAw88dahD38OjwSrQehwg7OEtDxl4y9sGC7Zlg/ojrpdES3XWc58Yu9lAz2Q5/IR 1QE04NFwsfuZVbrPfy7ogj+6nS8B+8itkJVvf+In30qxcHJx9zstAcr01h7Ic3BK/fa7 Drig== 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=ELbTtjDPPzz1LSUINCP/snN9sXJIkyQH8uWcUB3SXGE=; b=eYKzwqNvJiNOFI0+7CN1NPf/tJRScVy/RoTA7vcKEqlvN2mapHjBM+Y5vCBDQMZFcl 9Pj+wfWPZ8/aytbKSzNnjlhiyEf3S22GCct0WzI5QXLaLP0fxBPgnT74Dcru/7zrxPy+ LAJJ2xjtVH+kBKaMAAzR1W2w98CKMVfnpMl2IPLCFPB7rmNV0yofpvKjEozJRNFGKqbp DNpElnLlJT7tZilFMvQXd3VD+gkcZ/6uFiTLfq3mTGfWbYPuH7TupqvoAwE9LJDL+Vok LAkFLwooZ2lDPk3VJNNCfhVzJIrARl0oGmGr7kGlG4BHgEyLBM/hXad3ztrHGUV1hJo1 KcKQ== X-Gm-Message-State: AN3rC/5Vaqzxf//YT96s+IdRvnV0c1G4Bb3Tf9Gpyr3e7r22v/XhCuT+ dO9a+U0C0khduFzcyYO8wiYnyySG4FcS X-Received: by 10.36.10.12 with SMTP id 12mr22861581itw.74.1494269177846; Mon, 08 May 2017 11:46:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Mon, 8 May 2017 11:46:17 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> From: Brian Smith Date: Mon, 8 May 2017 08:46:17 -1000 Message-ID: To: David Benjamin Cc: Jim Schaad , curdle Content-Type: text/plain; charset=UTF-8 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: Mon, 08 May 2017 18:46:20 -0000 On David Benjamin wrote: > - When serializing without publicKey, serializing code SHOULD use v1 > (PrivateKeyInfo). v2 (OneAsymmetricKey) would also work, but this will be > less compatible. RFC 5958 says: > version identifies the version of OneAsymmetricKey. If publicKey > is present, then version is set to v2 else version is set to v1. This means if the publicKey is present, version MUST be v2. When publicKey is absent, version MUST be v1. (This is what we want, for interop with older implementations.) > - When parsing and the version is v2, parse as OneAsymmetricKey. When > parsing as OneAsymmetricKey, one MUST ignore trailing fields after the > OPTIONAL publicKey. I would rather not ignore trailing fields after publicKey. > - When parsing and the version is anything else, reject. This is some > invalid thing. Yep, I agree. Cheers, Brian -- https://briansmith.org/ From nobody Mon May 8 11: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 6537E12957C for ; Mon, 8 May 2017 11:55:08 -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 IE5SIAjLJG0f for ; Mon, 8 May 2017 11:55:07 -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 E3A351294A8 for ; Mon, 8 May 2017 11:55:06 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e64so37344856pfd.1 for ; Mon, 08 May 2017 11:55:06 -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=8kk1QZNVmAoYDt3wR63Rhxml04H+AVlaEJMK2crpJts=; b=GlzOu54ZV3FE9DfERx8aAYtGx53liOQNtPhq/PQ7M78rqybAT7yagSKhuPwaAzltWL J/HE6rV9FmoShxvXew7g+OFgEO8BUpMsEDmlEBs159lQf/4ofsti30xNx4VMXSncqqNa 23f8OJzdalpJMG+FU4rMNiXUbXmp4StrlOnHc= 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=8kk1QZNVmAoYDt3wR63Rhxml04H+AVlaEJMK2crpJts=; b=gVSZC2C+92f3SLfPLQrRYaAE/hQHmER1GhiZn6nPhKwhajGK/02IigAsUC1aw3XvCI k8jcb7mmphG8+5+z3h592legUWfjFFkB1uKkcEn5l8FHenjPuJjrbbqStdPtstubBx8o WSOSSf6p26YZLOGr74RzdhSyVGHl2hsdLT6KK1nQXCjoQj+QS4klB5kYQGwJbxml2RyF qZNjf1pG95Np2qw0tAN+7zHuCyNLhw++JrsN/u3euZVRfho0JvzK7dYI8oVOv4Rsf0sS YGDAr8aCdys9+V5lyAKIQ0rgtBTLaddmsRuvfnKIcUTbfQB/V8LcV3cF6mjGYtBzEMSn TMZQ== X-Gm-Message-State: AODbwcDMJiOqunYGpGlnI7xcLcUtD2Pw6Eing901pzmCtb3ojssiU5S6 ZO4Ix62gPSuVv6lnorPkm+6SlTkVMzSRxpM= X-Received: by 10.84.248.73 with SMTP id e9mr21901611pln.76.1494269706348; Mon, 08 May 2017 11:55:06 -0700 (PDT) MIME-Version: 1.0 References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <007001d2c820$6fc202a0$4f4607e0$@augustcellars.com> In-Reply-To: From: David Benjamin Date: Mon, 08 May 2017 18:54:54 +0000 Message-ID: To: Brian Smith Cc: Jim Schaad , curdle Content-Type: multipart/alternative; boundary=f403045fc4880befb1054f07c718 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: Mon, 08 May 2017 18:55:08 -0000 --f403045fc4880befb1054f07c718 Content-Type: text/plain; charset=UTF-8 On Mon, May 8, 2017 at 2:46 PM Brian Smith wrote: > On David Benjamin wrote: > > - When serializing without publicKey, serializing code SHOULD use v1 > > (PrivateKeyInfo). v2 (OneAsymmetricKey) would also work, but this will be > > less compatible. > > RFC 5958 says: > > version identifies the version of OneAsymmetricKey. If publicKey > > is present, then version is set to v2 else version is set to v1. > > This means if the publicKey is present, version MUST be v2. When > publicKey is absent, version MUST be v1. (This is what we want, for > interop with older implementations.) > Ah, I'd missed that. Yeah, being tighter's even better. > > - When parsing and the version is v2, parse as OneAsymmetricKey. When > > parsing as OneAsymmetricKey, one MUST ignore trailing fields after the > > OPTIONAL publicKey. > > I would rather not ignore trailing fields after publicKey. > Just to clarify, my comment was intended as a proposed concrete version of what Jim was saying. I am also fine with (and probably prefer) your version where we punt the X.680-level extensibility. But I also don't care much and just want there to be *some* concrete interpretation. :-) > > - When parsing and the version is anything else, reject. This is some > > invalid thing. > > Yep, I agree. > > Cheers, > Brian > -- > https://briansmith.org/ > --f403045fc4880befb1054f07c718 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 8,= 2017 at 2:46 PM Brian Smith <brian@briansmith.org> wrote:
On David Benjamin <davidben@chromium.org> wrote:
> - When serializing without publicKey, serializing code SHOULD use v1 > (PrivateKeyInfo). v2 (OneAsymmetricKey) would also work, but this will= be
> less compatible.

RFC 5958 says:
> version identifies the version of OneAsymmetricKey.=C2=A0 If publicKey=
> is present, then version is set to v2 else version is set to v1.

This means if the publicKey is present, version MUST be v2. When
publicKey is absent, version MUST be v1. (This is what we want, for
interop with older implementations.)

<= div dir=3D"ltr">
Ah, I'd missed that. Ye= ah, being tighter's even better.
=C2=A0
> - When parsing and the version is v2, parse as OneAsymmetricKey. When<= br> > parsing as OneAsymmetricKey, one MUST ignore trailing fields after the=
> OPTIONAL publicKey.

I would rather not ignore trailing fields after publicKey.
=

Just to clarify, my comment was intended as a proposed concrete version of= what Jim was saying. I am also fine with (and probably prefer) your versio= n where we punt the X.680-level extensibility. But I also don't care mu= ch and just want there to be *some* concrete interpretation. :-)
=C2=A0
> - When parsing and the version is anything else, reject. This is some<= br> > invalid thing.

Yep, I agree.

Cheers,
Brian
--
ht= tps://briansmith.org/
--f403045fc4880befb1054f07c718-- From nobody Mon May 8 12:39: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 E00631296C9 for ; Mon, 8 May 2017 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 dKQEOoSCXM9b for ; Mon, 8 May 2017 12:39:48 -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 CA60712969E for ; Mon, 8 May 2017 12:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3F8E830050E for ; Mon, 8 May 2017 15:39:48 -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 EiE7sLle_Yzx for ; Mon, 8 May 2017 15:39:45 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1776B30050D; Mon, 8 May 2017 15:39:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 8 May 2017 13:32:27 -0400 Cc: Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> References: To: curdle X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:39:50 -0000 > TECHNICAL > S 3.1 and 3.2. > - Is there some reason to not prescribe exactly one form here? > I.e., require id-sha512 (etc.) or require it not be there? >=20 > - Also, TLS has converged on talking about an "identity" hash > for the PureEd forms. Was this discussed and rejected? 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. = Eric is suggesting that the =E2=80=9Cidentity=E2=80=9D hash could be = used with Ed25519 and Ed448 when there are no attributes to hash. Using = ED25519 as an example, we get: IF (signed attributes are absent) THEN signedData.digestAlgorithms includes id-hashIdentity signedData.signerInfo.digestAlgorithm =3D id-hashIdentity signedData.signerInfo.signature =3D Ed25519(content) ELSE signedData.digestAlgorithms includes id-sha512 signedData.signerInfo.digestAlgorithm =3D id-sha512 signedData.signerInfo.signedAttrs includes message-digest =3D = SHA512(content) signedData.signerInfo.signature =3D = Ed25519(DER(signedData.signerInfo.signedAttrs)) Do others think the use of an algorithm identifier for the = =E2=80=9Cidentity=E2=80=9D hash is better? The current document include = id-sha512 as a warning that Ed25519 uses that hash algorithm internally. Russ= From nobody Mon May 8 12:39: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 4593E12969E for ; Mon, 8 May 2017 12:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 dokz8YY94u9F for ; Mon, 8 May 2017 12:39:48 -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 5F9FF127871 for ; Mon, 8 May 2017 12:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B6D6E300523 for ; Mon, 8 May 2017 15:39:47 -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 lnPilaSXwZlB for ; Mon, 8 May 2017 15:39:44 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C97A33004D8; Mon, 8 May 2017 15:39:44 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 8 May 2017 13:09:16 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <1E003270-BDF4-4894-85AE-DBFCF456EE5C@vigilsec.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:39:51 -0000 > TECHNICAL > S 3.1 and 3.2. > - The text here I think means "you can provide this hash and > if you do the parameters field of the hash MUST be absent". > Is that correct? I=E2=80=99m not sure what part of these sections you are asking about. = The answer is different for Ed25519 and Ed448. When signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, = and when the digestAlgorithm is provided, the algorithm parameters field = MUST be absent. When signing with Ed448, the digestAlgorithm SHOULD include = id-shake256-len, and when the digestAlgorithm is provided, the algorithm = parameters field MUST also be present, and the parameter MUST contain = 512, encoded as a positive integer value. > - Is there some reason to not prescribe exactly one form here? > I.e., require id-sha512 (etc.) or require it not be there? CMS provides the digestAlgorithm to facilitate stream process, but CMS = does not require that is be provided. This just follows past = convention. > - Also, TLS has converged on talking about an "identity" hash > for the PureEd forms. Was this discussed and rejected? Where =E2=80=9Cidentity=E2=80=9D means pass the whole to-be-hased input, = I assume. That approach would work for signed-data without signed = attributes, but I do not recall anyone suggesting it in this context. > EDITORIAL > RFC 7748 uses "curveXXX" not =E2=80=9CCurveXXX" Fixed. > S 2.1 > Each algorithms are identified by an object identifier, and the > algorithm identifier may contain parameters if needed. >=20 > Each algorithm is Fixed. > S 2.4. > Please note that || means =E2=80=9Cconcatenation" Fixed. Russ From nobody Mon May 8 14:17: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 BF0941201F8 for ; Mon, 8 May 2017 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uHfnfUmlvItR for ; Mon, 8 May 2017 14:17:50 -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 145FE1293E3 for ; Mon, 8 May 2017 14:17:50 -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=1494278266; h=from:subject:to:date:message-id; bh=sbJaaffshDlJGCoRbCZGAX3uUyhiAZgT4KcQbumnBC4=; b=MFVvUmTTz+p0Qiwvwus8YXO8K5mWtuD//cjKcpO9PozGDarGzvljWCHBSlAv58KcqBvLmfLUiJH IQXPrj4GQXlXkIa9nm0HziQzmlnFTBaXk9m1oRyYTTL4OQ2mM6aumiEGzE3Q70jCPVWbNnFpN93/J tTH3+Cy0lZdd8Ht62kSaWtMqZ2G5js7BEeg+dk3fO9mMW/KWpMe4Uh1nqpu/fxCKrKikTMIL5ykgY 511X/xxw0qyXzS304ZELRJg7vQOru4CQoqU1nyjIKDStMQK/mnWiUOcDKGJsZQuvWLtoFOcFS8yJ8 BFZekmzMwCkPYoJ4oJlIwrmrv0DQz9P/137w== 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; Mon, 8 May 2017 14:17:46 -0700 Received: from Hebrews (24.20.67.136) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 14:17:34 -0700 From: Jim Schaad To: 'Russ Housley' , 'curdle' CC: 'Eric Rescorla' References: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> In-Reply-To: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> Date: Mon, 8 May 2017 14:17:54 -0700 Message-ID: <009d01d2c840$906fbdb0$b14f3910$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDzjLssHQiGh7cNRgcgGtsfeGOhcALbPNLgo5KMffA= X-Originating-IP: [24.20.67.136] Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 21:17:52 -0000 -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, May 8, 2017 10:32 AM To: curdle Cc: Eric Rescorla Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-eddsa-signatures-05.txt > TECHNICAL > S 3.1 and 3.2. > - Is there some reason to not prescribe exactly one form here? > I.e., require id-sha512 (etc.) or require it not be there? >=20 > - Also, TLS has converged on talking about an "identity" hash > for the PureEd forms. Was this discussed and rejected? 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. = Eric is suggesting that the =E2=80=9Cidentity=E2=80=9D hash could be = used with Ed25519 and Ed448 when there are no attributes to hash. Using = ED25519 as an example, we get: IF (signed attributes are absent) THEN signedData.digestAlgorithms includes id-hashIdentity signedData.signerInfo.digestAlgorithm =3D id-hashIdentity signedData.signerInfo.signature =3D Ed25519(content) ELSE signedData.digestAlgorithms includes id-sha512 signedData.signerInfo.digestAlgorithm =3D id-sha512 signedData.signerInfo.signedAttrs includes message-digest =3D = SHA512(content) signedData.signerInfo.signature =3D = Ed25519(DER(signedData.signerInfo.signedAttrs)) Do others think the use of an algorithm identifier for the = =E2=80=9Cidentity=E2=80=9D hash is better? The current document include = id-sha512 as a warning that Ed25519 uses that hash algorithm internally. [JLS] Creation of an identity hash function would certainly be a good = way to give the hint that the entirety of the content is going to be = needed or the signature algorithm. As such it sounds like a good idea. = My worry would be about potential misuse of this as a hash function in = other contexts. For example, what happens if you used the identity hash = unction when signed attributes are present? Does this mean that you end = up with two copies of the content in the resulting SignedMessage object? = Where would it get abused that might be problematic.=20 On the balance however, I think this is a better idea than not having = the indicator. It is just going to need some caveats around it. I = still think I just prefer saying that you must have the attributes = present, but that ship is probably never going to sail. Jim Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Mon May 8 15:52: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 BA976124BE8 for ; Mon, 8 May 2017 15:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KjynQJj8tzUs for ; Mon, 8 May 2017 15:52:08 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 79C5F1200FC for ; Mon, 8 May 2017 15:52:08 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id l50so56000957wrc.3 for ; Mon, 08 May 2017 15:52:08 -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:content-transfer-encoding; bh=ro2VDthL5jrEpPVu017sithqywl46wApBzgS8Hx8dlY=; b=KNxA4V/kJjYILr3yl3S6EKeJ1s2G1hAF22iXtQcEecfjg0Ru3MBDZyh6LZDW+WU7FI v4eA3VHXFLHqnvbksrLUBFIaGyaX2fSiXNKggSvpTSeiNHiBwhzE5iTORaQs8y8eMDW5 7Uew4xeSC9RY5cGo4MILhKoUwttegWrn74yDjObrcPzELOMYnjUMrFWpxWinuoW9CkPH qEKTZQJyVxd33tfW1TEtYeKv5DKcr5LC/SOqCZS5ukFdcCfvWo5rAo/DmS7k0ygeGyjf 6MIf/w+2fTw+EYMxCMoPL4g2mPbpDqu19VBlmfvCQkm0fIxV4JbZ7gCbVwpZbNpZOV6K WMZg== 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:content-transfer-encoding; bh=ro2VDthL5jrEpPVu017sithqywl46wApBzgS8Hx8dlY=; b=FWIH66Pgsq/ByXMgwLAzPGMgDSXN5ZzpECROE63wrNn61EIuppT+BQ1TaBeh0BWrWn bAUYbJocTV3YMjJK5dxXCzkmsLfJteqMBV1kZB2uVVe1ioGEZttTXQlkCkPlA03GFzPI WKBDhC7/EN9NhckSrAgyJfj9jv+U+6PR0Mp+zsUnsxmufM0eYO8aEM/ndioE4Uoja3l1 oPnv0gEpkEg64mGnZf4C1zdg/Z8+eRjNUge6rwJ9fke/BIbqdS7C5zOKP8QA5+MQIljS c+RCIFXizgISkY4WfC/t4fT68ODnC1j7zpv0olAguX0fDeaq8OAq7YijyFXJwMU3JWUp V7Rg== X-Gm-Message-State: AODbwcBi9Xc+dPX7Or2pwF7i3roAiH8PnDRT8xGRKXQ43x8c7i7KI/6O rjq9nIKXeSvZ0ZBhc4BAVtWwvukenUAa X-Received: by 10.46.21.15 with SMTP id s15mr7363731ljd.50.1494283926941; Mon, 08 May 2017 15:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 15:52:06 -0700 (PDT) In-Reply-To: <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> From: Martin Thomson Date: Tue, 9 May 2017 08:52:06 +1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 22:52:11 -0000 Is there any reason why this couldn't be adopted in this working group? It's pretty firmly in scope from what I can see. FWIW, I think that the working group should adopt this. Comment on the draft: I think that you should say what the donation was *for*, namely the identification of the ECDH and EdDSA algorithms defined in . On 9 May 2017 at 03:34, Jim Schaad wrote: > I have written this document to make sure that the registration of the do= nated arc is dealt with correctly in the future. I intend to ask EKR to do= an AD sponsorship of the document if people do not see any issues. Please= review the document to make sure it is correct in terms of registrations t= hat have been done in the past in this arc. > > Note that I have placed a reservation in the table to allow for a subtree= to be created at a future date. > > Jim > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, May 8, 2017 10:31 AM > To: Jim Schaad ; Rick Andrews ; Rick Andrews > Subject: New Version Notification for draft-schaad-curdle-oid-registry-00= .txt > > > A new version of I-D, draft-schaad-curdle-oid-registry-00.txt > has been successfully submitted by Jim Schaad and posted to the IETF repo= sitory. > > Name: draft-schaad-curdle-oid-registry > Revision: 00 > Title: Object Identifier Registry for the Curdle Working Group > Document date: 2017-05-08 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-schaad-curdle-= oid-registry-00.txt > Status: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-= registry/ > Htmlized: https://tools.ietf.org/html/draft-schaad-curdle-oid-regis= try-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-schaad-curdle= -oid-registry-00 > > > Abstract: > When the Curdle Security Working Group was chartered, a range of > object identifiers was donated by Symantec Website Security for use > by that working group. This document describes the range of > identifiers that were assigned in that donated range, transfers > control of that range to IANA, and establishes IANA allocation > policies for any future assignments within that range. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon May 8 17:12:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46A12778D for ; Mon, 8 May 2017 17:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVwTcWQbDMjD for ; Mon, 8 May 2017 17:12:42 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1960127601 for ; Mon, 8 May 2017 17:12:41 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id 203so37301569ywe.0 for ; Mon, 08 May 2017 17:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxPBC4Wme6eBz2A8vHt7kZpr5uhfrB29TxN9u+HPW/I=; b=IqbpQz8JkWe72X2dpF3hyTlWCfzJds2gzbQsrY/ALu+rN5KVACLWojMM8ys4AiDYvr Dhyzm/dNRreBvqQ1rhAzXG4bSPQwb5pIbx86cCxxKd84vIv0XRx/Z5YKkwo/IcY84ynW uWyWJLiyYwwEW3CXfGX4DDyjxkSykbWYsUQzxBgYNP3+aG4anyUZvzPW/3R4h7rNA1Ez 4qqnAHZ8frNjFtdmRZfXu4lA6k/qeFrUyin2yNALHe/Ua9p1EgcqynSd2oMU7zYWD4pC ttKi1wN5E2/P3nPVaK8eY1Ghg4TsMkbCYtzJdnNW9CjUEU2930MIY1zBaOdpzie29Voj 3hEw== 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=zxPBC4Wme6eBz2A8vHt7kZpr5uhfrB29TxN9u+HPW/I=; b=fYX3Zqwh+VTTNkoY5m+iXVm2Yrik5ZnaVAdA06RPjsDMJJzmw5HUgY03pVUCEDbRh+ kAL2/eFRcgJKxc/+Q+6N7UcU2IacOZ+eVYbAU5X4s6K4kzwrBZbM2CifPSqdx2NbZlNa +I/ckaV7iy2fVH/4o5qJyXXl51g9rTZnBcAh5LtGvCf2XAwtPTqzaoDA8ceIuYZxmsAS 1/oK1yQm0V166C9/8FXDgrqZWDI6F7dz1lRd/abC1ADeUzeUaeS+TD49wQce8muRCKgo FvXAYjDaddcdO99dFa2xs+aNX/hpkwJBdTpw0iACPhlmISIdr5vniN6QkpevJef3rQcp 0zvA== X-Gm-Message-State: AN3rC/44US/e6GEEakhhpsVCUv3GueMY/8QjLthHYVKLWEBcXVQ4yaLA 3ZN7yZnKX4ZlUvGVjqPYJ/uDoY4bh8Ir X-Received: by 10.129.104.69 with SMTP id d66mr22921512ywc.74.1494288761051; Mon, 08 May 2017 17:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Mon, 8 May 2017 17:12:00 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 8 May 2017 17:12:00 -0700 Message-ID: To: Russ Housley Cc: curdle Content-Type: multipart/alternative; boundary=001a11490b9acc066d054f0c3659 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 00:12:43 -0000 --001a11490b9acc066d054f0c3659 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, May 6, 2017 at 2:27 PM, Russ Housley wrote: > Eric: > > > OVERALL > > I see a bunch of quasi-normative text here, e.g., > > > > [CURVES]. Those other curves are not deprecated, but support for > > curve25519 and curve448 is encouraged. > > > > Can you use RFC 2119 language here? > > The text says that other curves are not deprecated, but it is encouraging > support for X25519 and X448. We know that there are some communities tha= t > are not ready to embrace the CFRG curves over the NIST curves. So, I=E2= =80=99d > rather drop the second half of the sentence than change it to RFC 2119 > language. > OK. > TECHNICAL > > S 2. > > X25519 is described in Section 6.1 of [CURVES], and X448 is describe= d > > in Section 6.2 of [CURVES]. 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=E2=80=99s priva= te key. > > As described in Section 7 of [CURVES], implementations SHOULD detect > > this situation by checking for the all-zero output. > > > > Why are you not requiring this check? SSH and TLS both do. > > RFC 7748 [CURVES] says: > > 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. > > We upgraded the MAY to a SHOULD. We are being told that some > implementations will not perform this check, so it seemed wrong to go all > the way to MUST. > I'd like to push on this some, because I'm having trouble seeing why different IETF protocols have different needs. When you say "you are being told" is that an S/MIME specific point or merely the the text above? > > > The ECC-CMS-SharedInfo entityUInfo field optionally contains > > additional keying material supplied by the sending agent. Note that > > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > > SEQUENCE that includes the ukm field. If the ukm field is present, > > the ukm is placed in the entityUInfo field. The ukm value need not > > be longer than the key-encryption key that will be produced by the > > KDF. > > > > Need not? Please clarify what the purpose is here. It seems like > > it's to generate a unique KEK. In that case, the security bounds > > are what, uniqueness? > > I suggest this wording: > > =E2=80=A6 There is no security benefit to using a ukm value that is > longer than the key-encryption key that will be produced by > the KDF. > Hmm... I believe that this statement is true, but it also seems to be incomplete. I may be reasoning about this incorrectly, but it seems to me that the minimal security requirement is that the UKM be unique, but that can be achieved with a value much smaller than the KEK. For instance, it seems like if you have a 256-bit KEK, then you would still be OK with a randomly-generated 128-bit UKM. And if we're concerned about random collisions, then the usefulness bound is actually min(|KEK|, |hash compression function size|). > > S 9. > > This section is kinda diffident about whether the sender's > > ephemeral is truly ephemeral. Is this a MUST? If so, please > > say so. > > Section 2 already explains that the originator uses an ephemeral key pair= . > Yes, but it doesn't have any normative language (see above on this topic). > Appendix: > > How many people have checked this ASN.1 module? > > At least two people have compiled it with different toolsets. > > > EDITORIAL > > S 2. > > Please put KEK in parentheses in your first use. > > In most places, it is spelled out. I added (KEK) to the first place, and > left it in the other places. SGTM. > > > S 3. > > It would be easier to put this above the key derivation stage. > > I followed the outline used in other specifications. I figures that the > implementers were fine with the previous outline. > > > Please provide some sort of reference or cross-reference for > > =E2=80=9Ckari" > > The kari is defined in [CMS] as one of the choices in RecipientInfo. I > think that is clear from the sentence. > Yeah, I didn't find it super-clear. How about quoting it. -Ekr > > > KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires > > implementations to accept a KeyAgreeRecipientInfo SEQUENCE that > > includes the ukm field. If present, the ukm is placed in the > > entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. Th= e > > ukm value need not be longer than the key-encryption key produced by > > the KDF. > > > > This seems to be duplicated. > > Yes. I rewrote the text in Section 3.2 to point back to the earlier text= . > > > S 5. > > This also seems to be largely duplicated. Can you refactor out > > the common stuff. > > Because the content type is different, I think I already reduced it to th= e > minimum. > > Russ > > --001a11490b9acc066d054f0c3659 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, May 6, 2017 at 2:27 PM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
Eric:

> OVERALL
> I see a bunch of quasi-normative text here, e.g.,
>
>=C2=A0 =C2=A0 [CURVES].=C2=A0 Those other curves are not deprecated, bu= t support for
>=C2=A0 =C2=A0 curve25519 and curve448 is encouraged.
>
> Can you use RFC 2119 language here?

The text says that other curves are not deprecated, but it is encour= aging support for X25519 and X448.=C2=A0 We know that there are some commun= ities that are not ready to embrace the CFRG curves over the NIST curves.= =C2=A0 So, I=E2=80=99d rather drop the second half of the sentence than cha= nge it to RFC 2119 language.

OK.
<= div>

> TECHNICAL
> S 2.
>=C2=A0 =C2=A0 X25519 is described in Section 6.1 of [CURVES], and X448 = is described
>=C2=A0 =C2=A0 in Section 6.2 of [CURVES].=C2=A0 Since curve25519 and cu= rve448 have
>=C2=A0 =C2=A0 cofactors of 8 and 4, respectively, an input point of sma= ll order
>=C2=A0 =C2=A0 will eliminate any contribution from the other party=E2= =80=99s private key.
>=C2=A0 =C2=A0 As described in Section 7 of [CURVES], implementations SH= OULD detect
>=C2=A0 =C2=A0 this situation by checking for the all-zero output.
>
> Why are you not requiring this check? SSH and TLS both do.

RFC 7748 [CURVES] says:

=C2=A0 =C2=A0Protocol designers using Diffie-Hellman over the curves define= d in
=C2=A0 =C2=A0this document must not assume "contributory behaviour&quo= t;.=C2=A0 Specially,
=C2=A0 =C2=A0contributory behaviour means that both parties' private ke= ys
=C2=A0 =C2=A0contribute to the resulting shared key.=C2=A0 Since curve25519= and
=C2=A0 =C2=A0curve448 have cofactors of 8 and 4 (respectively), an input po= int of
=C2=A0 =C2=A0small order will eliminate any contribution f= rom the other party's
=C2=A0 =C2=A0private key.=C2=A0 This situation can be detected by ch= ecking for the all-
=C2=A0 =C2=A0zero output, which implementations MAY do, as specified in Sec= tion 6.
=C2=A0 =C2=A0However, a large number of existing implementations do not do = this.

We upgraded the MAY to a SHOULD.=C2=A0 We are being told that some implemen= tations will not perform this check, so it seemed wrong to go all the way t= o MUST.



>=C2=A0 =C2=A0 The ECC-CMS-SharedInfo entityUInfo field optionally conta= ins
>=C2=A0 =C2=A0 additional keying material supplied by the sending agent.= =C2=A0 Note that
>=C2=A0 =C2=A0 [CMS] requires implementations to accept a KeyAgreeRecipi= entInfo
>=C2=A0 =C2=A0 SEQUENCE that includes the ukm field.=C2=A0 If the ukm fi= eld is present,
>=C2=A0 =C2=A0 the ukm is placed in the entityUInfo field.=C2=A0 The ukm= value need not
>=C2=A0 =C2=A0 be longer than the key-encryption key that will be produc= ed by the
>=C2=A0 =C2=A0 KDF.
>
> Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness?

I suggest this wording:

=C2=A0 =C2=A0=E2=80=A6 There is no security benefit to using a ukm value th= at is
=C2=A0 =C2=A0longer than the key-encryption key that will = be produced by
=C2=A0 =C2=A0the KDF.



<= br> > S 9.
> This section is kinda diffident about whether the sender's
> ephemeral is truly ephemeral. Is this a MUST? If so, please
> say so.

Section 2 already explains that the originator uses an ephemeral key= pair.


> Appendix:
> How many people have checked this ASN.1 module?

At least two people have compiled it with different toolsets.

> EDITORIAL
> S 2.
> Please put KEK in parentheses in your first use.

In most places, it is spelled out.=C2=A0 I added (KEK) to the first = place, and left it in the other places.



> S 3.
> It would be easier to put this above the key derivation stage.

I followed the outline used in other specifications.=C2=A0 I figures= that the implementers were fine with the previous outline.

> Please provide some sort of reference or cross-reference for
> =E2=80=9Ckari"

The kari is defined in [CMS] as one of the choices in RecipientInfo.= =C2=A0 I think that is clear from the sentence.

Yeah, I didn't find it super-clear. How about quoting it.

-Ekr
=C2=A0

>=C2=A0 =C2=A0 KeyAgreeRecipientInfo ukm is optional.=C2=A0 Note that [C= MS] requires
>=C2=A0 =C2=A0 implementations to accept a KeyAgreeRecipientInfo SEQUENC= E that
>=C2=A0 =C2=A0 includes the ukm field.=C2=A0 If present, the ukm is plac= ed in the
>=C2=A0 =C2=A0 entityUInfo field of the ECC-CMS-SharedInfo as input to t= he KDF.=C2=A0 The
>=C2=A0 =C2=A0 ukm value need not be longer than the key-encryption key = produced by
>=C2=A0 =C2=A0 the KDF.
>
> This seems to be duplicated.

Yes.=C2=A0 I rewrote the text in Section 3.2 to point back to the ea= rlier text.

> S 5.
> This also seems to be largely duplicated. Can you refactor out
> the common stuff.

Because the content type is different, I think I already reduced it = to the minimum.

Russ


--001a11490b9acc066d054f0c3659-- From nobody Mon May 8 22:10: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 1ABF8129ABE for ; Mon, 8 May 2017 22:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02G3hMQXDxjD for ; Mon, 8 May 2017 22:10:43 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 D4B11129AB6 for ; Mon, 8 May 2017 22:10:42 -0700 (PDT) X-AuditID: 12074423-739ff70000003b31-b5-59114f501758 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5A.46.15153.05F41195; Tue, 9 May 2017 01:10:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v495AdfM005425; Tue, 9 May 2017 01:10:39 -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 v495AXn0023496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2017 01:10:36 -0400 Date: Tue, 9 May 2017 00:10:32 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: Jim Schaad , curdle Message-ID: <20170509051032.GZ30306@kduck.kaduk.org> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT0Q30F4w06GpStti6cBazxerp39ks rp35x+jA7LFxznQ2j52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoErY9OBhewFjcwVj7ZPY2lg XMPUxcjJISFgIrF78WqWLkYuDiGBxUwS27v3sEM4Gxglvl5dyQhSJSRwhUni3YlCEJtFQEWi Zf8cFhCbDchu6L7MDGKLCOhKLDr7gB3EZhZwlHhx6TRYr7BAgsTDsw1sIDYv0LYb706xQsw8 zSjRtd8eIi4ocXLmExaIXi2JG/9eAl3HAWRLSyz/xwES5hQIlFh5pA1sjKiAskTDjAfMExgF ZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Znq5mSV6qSmlmxjBgeuivIPx ZZ/3IUYBDkYlHl6NPIFIIdbEsuLK3EOMkhxMSqK8PsVAIb6k/JTKjMTijPii0pzU4kOMEhzM SiK8y5wEI4V4UxIrq1KL8mFS0hwsSuK84hqNEUIC6YklqdmpqQWpRTBZGQ4OJQneMD+gRsGi 1PTUirTMnBKENBMHJ8hwHqDhbSA1vMUFibnFmekQ+VOMuhxz7n19zyTEkpeflyolzuvkC1Qk AFKUUZoHNweUcCSy99e8YhQHekuY9yJIFQ8wWcFNegW0hAloSSCDAMiSkkSElFQDo1xn7X3H aKYs0Y+vJ/1pfR67qMha4H7pU76/loo/X89489Dn8KzPRxmnK9oL/5e/w9obd7w1f1Kv+sfr 90LeuuypSj8cOIl7+vq2r/ta1dfyP9i2k/Hajc+2TPyS6y4993izeVpM6K2bZ9wWyS7k1ane rq7T+2D/3QWmtlMebE/lvC7i0FWwUkyJpTgj0VCLuag4EQBE2V54EwMAAA== Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 05:10:44 -0000 On Tue, May 09, 2017 at 08:52:06AM +1000, Martin Thomson wrote: > Is there any reason why this couldn't be adopted in this working > group? It's pretty firmly in scope from what I can see. FWIW, I > think that the working group should adopt this. It's uncontroversial and the AD-sponsored path might shave a couple weeks off it? But, I am +1 for adoption as well. -Ben From nobody Mon May 8 22:27: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 6B3F9129ACC for ; Mon, 8 May 2017 22:27:03 -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 Git4usn-AsXB for ; Mon, 8 May 2017 22:27:01 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8151A127B52 for ; Mon, 8 May 2017 22:27:01 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id u65so107422045wmu.1 for ; Mon, 08 May 2017 22:27:01 -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=p+vsc0w/ToMz8uCsK2m26WOXs7CkQciuYMGFec0Pqgw=; b=Lw+aLjjEKb0EHXKHl9kC4z+KH2NlJIp/uvDuEYwPFclosb3pPoQEVaJgSP07M8Fh0Z mKdLfVpXhvAz/6wjOYcxIG5KNki0RcitTIrsJ2cB+lS35n9L/iqDLjn3L/IVid/XVW0f mSctR7jHvLgQWWSQcywYOiVgpnv/eip1hNFNhnzuzkwMTbgjHyJ+4OYPzVhTmD50Gi7s QqZFYnGZb2jgWStwAM0Pyi8+He7voUVIkzXv0DbO79tiXXxusbjDvfWYcvQukFUJpiIQ KYoafpO92YpFfHgqCLXEWEpcci91fC1usTrnZjsJoFhSYq+csnmWXqWKwzmEWIW7tAjn +QSw== 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=p+vsc0w/ToMz8uCsK2m26WOXs7CkQciuYMGFec0Pqgw=; b=ksmF1hKg0SO7UqYuXW+peBXFaoktH8vcKZTBrO7yhcfOKou1tKvg7sAOQJZv8i+VR7 vMKJ3syVrH1Fp9fJd/LOhgZVmcI9IC7mXkDg1qaYchodj8LsPiSzbYPkd8O2JmIS4a0K Fcdjpz6lFVMOaN7fPmm7mlftoyuotQHanzOtnvAC04iFWUSS/1WIjaQSofjWJBTJGBLx 4DMzSQzVYqasbwDKAf2jIbZxLPRPTLrXEw4YRRLaZu8UZ8sigqOE1s6SviA+nMD45TAb 1DG+Z9k/t6MyoPdZ+oE5KWSfVTvPxmMu17jx+yvtjBJHTVAXCBuQUADWed6qUOz90zYm kbVA== X-Gm-Message-State: AN3rC/5ZIeqarDMhPFtTCei5gETn9pd42kBWa+LB/3OIW6cdX9veIXpN NTuP/aDtdxSLtiE7ONQnnzmfhXYyA68Q X-Received: by 10.25.79.27 with SMTP id d27mr23383956lfb.76.1494307620061; Mon, 08 May 2017 22:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 22:26:59 -0700 (PDT) In-Reply-To: <20170509051032.GZ30306@kduck.kaduk.org> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> From: Martin Thomson Date: Tue, 9 May 2017 15:26:59 +1000 Message-ID: To: Benjamin Kaduk Cc: Jim Schaad , curdle Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 05:27:03 -0000 On 9 May 2017 at 15:10, Benjamin Kaduk wrote: > It's uncontroversial and the AD-sponsored path might shave a couple > weeks off it? I'm pushing back on this pattern when I see it. AD sponsorship puts more work on an individual; the same goes for publication on the independent stream. If there is a problem with the efficiency of working groups, using these alternative routes lets the problem fester. I suspect that - more often than not - the problem is lack of energy or lack of consensus. From nobody Mon May 8 22:53: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 DF199129AD8 for ; Mon, 8 May 2017 22:53:12 -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 8FSv7bL-GkJi for ; Mon, 8 May 2017 22:53:11 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 68E531294E2 for ; Mon, 8 May 2017 22:53:11 -0700 (PDT) X-AuditID: 1209190d-18dff70000005e44-a3-5911594321d5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 37.4A.24132.44951195; Tue, 9 May 2017 01:53:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v495r7HI008334; Tue, 9 May 2017 01:53:07 -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 v495r2B7000526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2017 01:53:05 -0400 Date: Tue, 9 May 2017 00:53:01 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: Jim Schaad , curdle Message-ID: <20170509055301.GB30306@kduck.kaduk.org> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT0XWNFIw0+HLH3GLrwlnMFqunf2ez uHbmH6MDs8fGOdPZPHbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujMvNtQVNbBWbd79nb2C8 ydLFyMkhIWAiceDSE6YuRi4OIYHFTBL7fh5lh3A2MEpMvH8VyrnCJLHoaytYC4uAisTzzbOZ QWw2ILuh+zKYLSKgK7Ho7AN2EJtZwFHixaXTjCC2sECCxMOzDWwgNi/QunPzQeaADN3LJHH0 yQpmiISgxMmZT1ggmrUkbvx7CXQTB5AtLbH8HwdImFMgUOL124tg5aICyhINMx4wT2AUmIWk exaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIEhS6nJO8Oxn93 vQ4xCnAwKvHwauQJRAqxJpYVV+YeYpTkYFIS5fUpBgrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4b0SIBgpxJuSWFmVWpQPk5LmYFES5xXXaIwQEkhPLEnNTk0tSC2CycpwcChJ8F4NB2oULEpN T61Iy8wpQUgzcXCCDOcBGv4OpIa3uCAxtzgzHSJ/ilGXY869r++ZhFjy8vNSpcR5C0GKBECK Mkrz4OaAUo5E9v6aV4ziQG8J834DqeIBpiu4Sa+AljABLQlkEABZUpKIkJJqYJQoVGxzWrLo 1cL9k2bd1z0tL3FxQeWfurCvLIVMXMmLxKLCp5h94Zt7J3m5b0mVxrwuyasWPt+lOP4yGhRa 2gvtYajPmmbu/XLKUSaThF7NaQWHBTYYnvHsPJ17Ze/SF0zpTg5blddvq/XlvsG/oiN9o9KU mG2Vd9mE81zsbdR5vL/0/eb7qcRSnJFoqMVcVJwIAEXnSeIUAwAA Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 05:53:13 -0000 On Tue, May 09, 2017 at 03:26:59PM +1000, Martin Thomson wrote: > On 9 May 2017 at 15:10, Benjamin Kaduk wrote: > > It's uncontroversial and the AD-sponsored path might shave a couple > > weeks off it? > > > I'm pushing back on this pattern when I see it. AD sponsorship puts > more work on an individual; the same goes for publication on the > independent stream. You asked for "any reason", not "any good reason" :-P You're right to push back on it... > If there is a problem with the efficiency of working groups, using > these alternative routes lets the problem fester. I suspect that - > more often than not - the problem is lack of energy or lack of > consensus. Lots of lack of energy in places I frequent, alas. -Ben From nobody Tue May 9 09:03: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 4BA90129413 for ; Tue, 9 May 2017 09:03:50 -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 1wzfUCmW3XgM for ; Tue, 9 May 2017 09:03:48 -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 0A6F912E6D7 for ; Tue, 9 May 2017 09:03:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 663833004DB for ; Tue, 9 May 2017 12:03:47 -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 MyYUtJLHM2Qv for ; Tue, 9 May 2017 12:03:44 -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 9071730024B; Tue, 9 May 2017 12:03:44 -0400 (EDT) From: Russ Housley Message-Id: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_979512E3-808C-4B9F-B938-B3BF067930BF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 12:03:44 -0400 In-Reply-To: Cc: curdle To: Eric Rescorla References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 16:03:50 -0000 --Apple-Mail=_979512E3-808C-4B9F-B938-B3BF067930BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I dropped the parts that have been resolved. > > TECHNICAL > > S 2. > > X25519 is described in Section 6.1 of [CURVES], and X448 is = described > > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. > > As described in Section 7 of [CURVES], implementations SHOULD = detect > > this situation by checking for the all-zero output. > > > > Why are you not requiring this check? SSH and TLS both do. >=20 > RFC 7748 [CURVES] says: >=20 > 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. >=20 > We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. >=20 > I'd like to push on this some, because I'm having trouble seeing why = different IETF protocols have different needs. When you say "you are = being told" is that an S/MIME specific point or merely the the text = above? The text above, which I gather is about some existing implementations, = probably libraries. I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols. > > The ECC-CMS-SharedInfo entityUInfo field optionally contains > > additional keying material supplied by the sending agent. Note = that > > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > > SEQUENCE that includes the ukm field. If the ukm field is = present, > > the ukm is placed in the entityUInfo field. The ukm value need = not > > be longer than the key-encryption key that will be produced by = the > > KDF. > > > > Need not? Please clarify what the purpose is here. It seems like > > it's to generate a unique KEK. In that case, the security bounds > > are what, uniqueness? >=20 > I suggest this wording: >=20 > =E2=80=A6 There is no security benefit to using a ukm value that is > longer than the key-encryption key that will be produced by > the KDF. >=20 > Hmm... I believe that this statement is true, but it also seems to be > incomplete. I may be reasoning about this incorrectly, but it seems > to me that the minimal security requirement is that the UKM be > unique, but that can be achieved with a value much smaller than > the KEK. For instance, it seems like if you have a 256-bit KEK, > then you would still be OK with a randomly-generated 128-bit > UKM. And if we're concerned about random collisions, then the > usefulness bound is actually min(|KEK|, |hash compression function = size|). Yes. The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? > > S 9. > > This section is kinda diffident about whether the sender's > > ephemeral is truly ephemeral. Is this a MUST? If so, please > > say so. >=20 > Section 2 already explains that the originator uses an ephemeral key = pair. >=20 > Yes, but it doesn't have any normative language (see above on this = topic). I see. I=E2=80=99ll reword the text in Section 2 to use MUST. How about: The originator MUST use an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair MUST be used for a single CMS protected content type, and then it MUST be discarded. The originator obtains the recipient's static public key from the recipient's certificate [PROFILE]. > > S 3. > > It would be easier to put this above the key derivation stage. >=20 > I followed the outline used in other specifications. I figures that = the implementers were fine with the previous outline. >=20 > > Please provide some sort of reference or cross-reference for > > =E2=80=9Ckari" >=20 > The kari is defined in [CMS] as one of the choices in RecipientInfo. = I think that is clear from the sentence. >=20 > Yeah, I didn't find it super-clear. How about quoting it. Okay. I suggest: The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as described in Section 6 of [CMS]. The RecipientInfo choice is described in Section 6.2 of [CMS], and repeated here for convenience. RecipientInfo ::=3D CHOICE { ktri KeyTransRecipientInfo, kari [1] KeyAgreeRecipientInfo, kekri [2] KEKRecipientInfo, pwri [3] PasswordRecipientinfo, ori [4] OtherRecipientInfo } For the recipients that use X25519 or X448 the RecipientInfo kari choice MUST be used. Russ --Apple-Mail=_979512E3-808C-4B9F-B938-B3BF067930BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I dropped the parts that have been = resolved.

> TECHNICAL
> S 2.
>    X25519 is described in Section 6.1 of [CURVES], and = X448 is described
>    in Section 6.2 of [CURVES].  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=E2=80=99s private key.
>    As described in Section 7 of [CURVES], implementations = SHOULD detect
>    this situation by checking for the all-zero output.
>
> Why are you not requiring this check? SSH and TLS both do.

RFC 7748 [CURVES] says:

   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.

We upgraded the MAY to a SHOULD.  We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST.

I'd like to push on this some, because = I'm having trouble seeing why different IETF protocols have different = needs. When you say "you are being told" is that an S/MIME specific = point or merely the the text = above?

The = text above, which I gather is about some existing implementations, = probably libraries.  I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols.


>    The ECC-CMS-SharedInfo entityUInfo field optionally = contains
>    additional keying material supplied by the sending = agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that includes the ukm field.  If the ukm = field is present,
>    the ukm is placed in the entityUInfo field.  The = ukm value need not
>    be longer than the key-encryption key that will be = produced by the
>    KDF.
>
> Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the security bounds
> are what, uniqueness?

I suggest this wording:

   =E2=80=A6 There is no security benefit to using a ukm value = that is
   longer than the key-encryption key that = will be produced by
   the KDF.

Hmm... I believe that = this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me that the minimal security requirement = is that the UKM be
unique, but that can be achieved = with a value much smaller than
the KEK. For = instance, it seems like if you have a 256-bit KEK,
then you would still be OK with a randomly-generated = 128-bit
UKM. And if we're concerned about random = collisions, then the
usefulness bound is actually = min(|KEK|, |hash compression function = size|).

Yes.= The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced.  Of course, an implementation will = generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.

Are you asking for a sentence saying that the ukm, = if present, MUST be at least 128 bits?


> S 9.
> This section is kinda diffident about whether the sender's
> ephemeral is truly ephemeral. Is this a MUST? If so, please
> say so.

Section 2 already explains that the originator uses an ephemeral = key pair.

Yes, but it doesn't have any normative = language (see above on this = topic).

I = see.  I=E2=80=99ll reword the text in Section 2 to use = MUST.

How about:

   The originator MUST use an = ephemeral public/private key pair that is
  =  generated on the same elliptic curve as the public key of = the
   recipient.  The ephemeral key pair MUST = be used for a single CMS
   protected content type, = and then it MUST be discarded.  The
  =  originator obtains the recipient's static public key from = the
   recipient's certificate = [PROFILE].


> S 3.
> It would be easier to put this above the key derivation stage.

I followed the outline used in other specifications.  I = figures that the implementers were fine with the previous outline.

> Please provide some sort of reference or cross-reference for
> =E2=80=9Ckari"

The kari is defined in [CMS] as one of the choices in = RecipientInfo.  I think that is clear from the sentence.

Yeah, I didn't find it super-clear. How about quoting = it.

Okay. =  I suggest:

  =  The enveloped-data content type is ASN.1 encoded using = the
   EnvelopedData syntax.  The fields of the = EnvelopedData syntax MUST be
   populated as = described in Section 6 of [CMS].  The = RecipientInfo
   choice is described in Section 6.2 = of [CMS], and repeated here for
  =  convenience.

    =   RecipientInfo ::=3D CHOICE {
      =   ktri KeyTransRecipientInfo,
        = kari [1] KeyAgreeRecipientInfo,
        = kekri [2] KEKRecipientInfo,
        pwri = [3] PasswordRecipientinfo,
        ori [4] = OtherRecipientInfo }

  =  For the recipients that use X25519 or X448 the RecipientInfo = kari
   choice MUST be used.

Russ

= --Apple-Mail=_979512E3-808C-4B9F-B938-B3BF067930BF-- From nobody Tue May 9 10:47: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 38C3F127076 for ; Tue, 9 May 2017 10:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl-S_0TiV7RT for ; Tue, 9 May 2017 10:47:31 -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 3318A126CE8 for ; Tue, 9 May 2017 10:47:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01D2C8B1.AC101F30" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494352048; h=from:subject:to:date:message-id; bh=Rb4KiKVdaqtSWzeEgGehbNd8q2tLG76rDMFX23Pku18=; b=Y0wpa6uR6RPpfcPfTe0DsLEx9FupDZjPdr1yV3xuYsLwJqkB2BNWv0FYwv9RY4DfrN7zEa2MY7u 5o11pcUKcscoWOZr4duSXihg5dqWPasCBSwmmrWmKp2SYMq5e+AIGKPyDyYYL/tl+W2DtVZjLYFOC ppSlZCEcai39dY1Y/ZvGbE7/PZDMH+QAnsHZgyQt+Y0o/9yuji7uY2QFPO16wfnTtGzpAffihfp4B 6IqocTUQwvTt/ar1Vj3nDgo6vd/Jf4eNo2cZWvkvMcg123UZ9/WisiUmuRwzbJb+1s8eOQqfVpCtD Uh1/2CsCH37EGmcal7g6hK3nvJZ6yRDVcC3g== 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, 9 May 2017 10:47:27 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 10:47:13 -0700 From: Jim Schaad To: 'Russ Housley' , 'Eric Rescorla' CC: 'curdle' References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> In-Reply-To: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> Date: Tue, 9 May 2017 10:47:33 -0700 Message-ID: <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH9xBMcsIwTVYthAE2k4UvXwpKedQIe2gLjAVvwxw4CXdRt+aFnibtA X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 17:47:34 -0000 ------=_NextPart_000_0132_01D2C8B1.AC101F30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See inline. =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, May 9, 2017 9:04 AM To: Eric Rescorla Cc: curdle Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt =20 I dropped the parts that have been resolved. > TECHNICAL > S 2. > X25519 is described in Section 6.1 of [CURVES], and X448 is = described > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. > As described in Section 7 of [CURVES], implementations SHOULD = detect > this situation by checking for the all-zero output. > > Why are you not requiring this check? SSH and TLS both do. RFC 7748 [CURVES] says: 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. We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. =20 I'd like to push on this some, because I'm having trouble seeing why = different IETF protocols have different needs. When you say "you are = being told" is that an S/MIME specific point or merely the the text = above? =20 The text above, which I gather is about some existing implementations, = probably libraries. I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols. =20 [JLS] As I have stated in the past =E2=80=93 I am with EKR on this. > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note = that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. The ukm value need not > be longer than the key-encryption key that will be produced by the > KDF. > > Need not? Please clarify what the purpose is here. It seems like > it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness? I suggest this wording: =E2=80=A6 There is no security benefit to using a ukm value that is longer than the key-encryption key that will be produced by the KDF. =20 Hmm... I believe that this statement is true, but it also seems to be incomplete. I may be reasoning about this incorrectly, but it seems to me that the minimal security requirement is that the UKM be unique, but that can be achieved with a value much smaller than the KEK. For instance, it seems like if you have a 256-bit KEK, then you would still be OK with a randomly-generated 128-bit UKM. And if we're concerned about random collisions, then the usefulness bound is actually min(|KEK|, |hash compression function = size|). =20 Yes. The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. =20 Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? =20 [JLS] I would disagree that the value has to be random, a counter will = work as well. (An encrypted counter is better.) I not be happy with a = fixed size requirement on this easier. There is no reason to make such = a requirement that I can think of. A 64-bit counter is just as = rational. It might make more sense to change this statement into = something along the lines of=20 =20 * Any pair of static keys MUST NOT be used more times than the size of = the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on the number of times the key pair can be used. * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. Jim =20 > S 9. > This section is kinda diffident about whether the sender's > ephemeral is truly ephemeral. Is this a MUST? If so, please > say so. Section 2 already explains that the originator uses an ephemeral key = pair. =20 Yes, but it doesn't have any normative language (see above on this = topic). =20 I see. I=E2=80=99ll reword the text in Section 2 to use MUST. =20 How about: =20 The originator MUST use an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair MUST be used for a single CMS protected content type, and then it MUST be discarded. The originator obtains the recipient's static public key from the recipient's certificate [PROFILE]. =20 > S 3. > It would be easier to put this above the key derivation stage. I followed the outline used in other specifications. I figures that the = implementers were fine with the previous outline. > Please provide some sort of reference or cross-reference for > =E2=80=9Ckari" The kari is defined in [CMS] as one of the choices in RecipientInfo. I = think that is clear from the sentence. =20 Yeah, I didn't find it super-clear. How about quoting it. =20 Okay. I suggest: =20 The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as described in Section 6 of [CMS]. The RecipientInfo choice is described in Section 6.2 of [CMS], and repeated here for convenience. =20 RecipientInfo ::=3D CHOICE { ktri KeyTransRecipientInfo, kari [1] KeyAgreeRecipientInfo, kekri [2] KEKRecipientInfo, pwri [3] PasswordRecipientinfo, ori [4] OtherRecipientInfo } =20 For the recipients that use X25519 or X448 the RecipientInfo kari choice MUST be used. =20 Russ =20 ------=_NextPart_000_0132_01D2C8B1.AC101F30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

See inline.

 

From: Curdle = [mailto:curdle-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Tuesday, May 9, 2017 9:04 AM
To: Eric = Rescorla <ekr@rtfm.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

I = dropped the parts that have been resolved.



> = TECHNICAL
> S 2.
>    X25519 is described in = Section 6.1 of [CURVES], and X448 is described
>    in = Section 6.2 of [CURVES].  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=E2=80=99s private key.
>  =   As described in Section 7 of [CURVES], implementations SHOULD = detect
>    this situation by checking for the all-zero = output.
>
> Why are you not requiring this check? SSH and = TLS both do.

RFC 7748 [CURVES] says:

   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.

We upgraded the MAY to a SHOULD.  We are being told = that some implementations will not perform this check, so it seemed = wrong to go all the way to MUST.

 

I'd like to push on this some, because I'm having = trouble seeing why different IETF protocols have different needs. When = you say "you are being told" is that an S/MIME specific point = or merely the the text = above?

The = text above, which I gather is about some existing implementations, = probably libraries.  I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols.

[JLS] As I have stated = in the past =E2=80=93 I am with EKR on = this.

>    The ECC-CMS-SharedInfo entityUInfo = field optionally contains
>    additional keying = material supplied by the sending agent.  Note that
>  =   [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that includes the = ukm field.  If the ukm field is present,
>    the = ukm is placed in the entityUInfo field.  The ukm value need = not
>    be longer than the key-encryption key that will = be produced by the
>    KDF.
>
> Need not? = Please clarify what the purpose is here. It seems like
> it's to = generate a unique KEK. In that case, the security bounds
> are = what, uniqueness?

I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that will be = produced by
   the KDF.

Yes. = The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced.  Of course, an implementation will = generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.

[JLS] I would disagree = that the value has to be random, a counter will work as well.=C2=A0 (An = encrypted counter is better.)=C2=A0 I not be happy with a fixed size = requirement on this easier.=C2=A0 There is no reason to make such a = requirement that I can think of.=C2=A0 A 64-bit counter is just as = rational.=C2=A0 It might make more sense to change this statement into = something along the lines of

 

* Any pair of static = keys MUST NOT be used more times than the size of the key.=C2=A0 I.e. if = 128-bit KEKs may be used, then there is a 2^128 limit on the number of = times the key pair can be used.

* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any = event.

Jim

 

I see. =  I=E2=80=99ll reword the text in Section 2 to use = MUST.

Okay. =  I suggest:

------=_NextPart_000_0132_01D2C8B1.AC101F30-- From nobody Tue May 9 10:51: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 AC28E129512 for ; Tue, 9 May 2017 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRKj0zhqC8yB for ; Tue, 9 May 2017 10:51:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0FE127076 for ; Tue, 9 May 2017 10:51:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l14so4308731ywk.1 for ; Tue, 09 May 2017 10:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xtyDCVY4NKvSrBBkXoAslA8YlHLbSELC7VUtdwgy0A0=; b=L/b1MvCCG3Rd65nkCEL3utjxsdj7JCg+ekq6TSDaH0eRIBRkiMWlxzZR8se8z1Bo0/ kYUNwy8K3AE1yEckSR9xNK5DvpGM6vuVdiVuSPa0hf5QXlDMD679e92+x2KsadOxNHK+ ikilUtwNyinc6llyOblIOeJ4Hyx8Pmq54OC0aTWLGJXaECk1Py3t79sYfsou0LOXmDUi A4ZWk0oeWG23ldwvYiGjYzhBGwWepBhSoI3EO+yWsEGgiL3tNfJkOAQN9KYSPB+UUA18 e65ejJv+4MagX7IEZ9zFLzNMPP9z0WmL9BKkd+2g0XZ/2cy+J3ACnvJm2QLBOgrpgZXZ od8g== 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=xtyDCVY4NKvSrBBkXoAslA8YlHLbSELC7VUtdwgy0A0=; b=djyWqkdDQFsKov2H79hUIFn3P/d+GmhA4rs07WjTY0IQHER/7qHsONg+T0EMg51DER 7m9mfr4t7m8JlaW6MbdBseNly03ljaQS/bmog9X6J4yiBd8mEXC3a5uv5RQhdoeU/nWX f09I0NiM725FIOl/h73PJEWUWTkAukrqxTp/+PSzdnGKIOMRbpPz4vx6pjuVCwbB/trd c8OXTT94dowSHbomgwKxW0RiZOtNuQ2arxNBuDbh49jnukr3lJZSzXVxZPKCcpHEH7Gn L016oBv+edzXEDsf260Xmm1pn8f6O1teiAIHhaHgt2rkzEnJFlItViaZmjZW0j24n7Qa M53w== X-Gm-Message-State: AODbwcDCW+tFBO+c9/+QQyEMwQ3KFXYVklOsPpR48UT0CEEJGCMM0PUr +kO0gseP5bq0Na4uDN1qrdKECZlew9cs X-Received: by 10.129.5.14 with SMTP id 14mr1066838ywf.85.1494352293359; Tue, 09 May 2017 10:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 9 May 2017 10:50:52 -0700 (PDT) In-Reply-To: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> From: Eric Rescorla Date: Tue, 9 May 2017 10:50:52 -0700 Message-ID: To: Russ Housley Cc: curdle Content-Type: multipart/alternative; boundary=001a114174689da2bc054f1b01b8 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 17:51:37 -0000 --001a114174689da2bc054f1b01b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 9, 2017 at 9:03 AM, Russ Housley wrote: > I dropped the parts that have been resolved. > > > TECHNICAL >> > S 2. >> > X25519 is described in Section 6.1 of [CURVES], and X448 is describ= ed >> > in Section 6.2 of [CURVES]. 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=E2=80=99s priv= ate key. >> > As described in Section 7 of [CURVES], implementations SHOULD detec= t >> > this situation by checking for the all-zero output. >> > >> > Why are you not requiring this check? SSH and TLS both do. >> >> RFC 7748 [CURVES] says: >> >> 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. >> >> We upgraded the MAY to a SHOULD. We are being told that some >> implementations will not perform this check, so it seemed wrong to go al= l >> the way to MUST. >> > > I'd like to push on this some, because I'm having trouble seeing why > different IETF protocols have different needs. When you say "you are bein= g > told" is that an S/MIME specific point or merely the the text above? > > > The text above, which I gather is about some existing implementations, > probably libraries. I do not know what protocols use those > implementations, but if they are libraries they will get used with many > different protocols. > Sure, but other protocols are requiring it and it seems like S/MIME could also do so, in the worst case at the point where Z is handed off to S/MIME. > > > > The ECC-CMS-SharedInfo entityUInfo field optionally contains >> > additional keying material supplied by the sending agent. Note tha= t >> > [CMS] requires implementations to accept a KeyAgreeRecipientInfo >> > SEQUENCE that includes the ukm field. If the ukm field is present, >> > the ukm is placed in the entityUInfo field. The ukm value need not >> > be longer than the key-encryption key that will be produced by the >> > KDF. >> > >> > Need not? Please clarify what the purpose is here. It seems like >> > it's to generate a unique KEK. In that case, the security bounds >> > are what, uniqueness? >> >> I suggest this wording: >> >> =E2=80=A6 There is no security benefit to using a ukm value that is >> longer than the key-encryption key that will be produced by >> the KDF. >> > > Hmm... I believe that this statement is true, but it also seems to be > incomplete. I may be reasoning about this incorrectly, but it seems > to me that the minimal security requirement is that the UKM be > unique, but that can be achieved with a value much smaller than > the KEK. For instance, it seems like if you have a 256-bit KEK, > then you would still be OK with a randomly-generated 128-bit > UKM. And if we're concerned about random collisions, then the > usefulness bound is actually min(|KEK|, |hash compression function size|)= . > > > Yes. The umm value needs to be different for each invocation of the KDF, > otherwise it does not provide the assurance that different keying materia= l > will be produced. Of course, an implementation will generate the umm val= ue > using random number generator, not track the values that are used. Sever= al > years ago, there was a discussion about the size of the ukm needed. Some > people were suggesting crazy large values, and the point was made that > anything beyond the SIZEOF(KEK) did not improve security. > > Are you asking for a sentence saying that the ukm, if present, MUST be at > least 128 bits? > Sorry, I was trying to talk it over, but I'm not sure how helpful I am being. It seems like the basic requirement is that it be unique and that if we want to give guidance it should be on the collision probability. Do we believe that 128 bits is enough (I do!), in which case we can just say "if you are generating it randomly, then N bits is enough" > S 9. >> > This section is kinda diffident about whether the sender's >> > ephemeral is truly ephemeral. Is this a MUST? If so, please >> > say so. >> >> Section 2 already explains that the originator uses an ephemeral key pai= r. >> > > Yes, but it doesn't have any normative language (see above on this topic)= . > > > I see. I=E2=80=99ll reword the text in Section 2 to use MUST. > > How about: > > The originator MUST use an ephemeral public/private key pair that is > generated on the same elliptic curve as the public key of the > recipient. The ephemeral key pair MUST be used for a single CMS > protected content type, and then it MUST be discarded. The > originator obtains the recipient's static public key from the > recipient's certificate [PROFILE]. > LGTM. > > > > S 3. >> > It would be easier to put this above the key derivation stage. >> >> I followed the outline used in other specifications. I figures that the >> implementers were fine with the previous outline. >> >> > Please provide some sort of reference or cross-reference for >> > =E2=80=9Ckari" >> >> The kari is defined in [CMS] as one of the choices in RecipientInfo. I >> think that is clear from the sentence. >> > > Yeah, I didn't find it super-clear. How about quoting it. > > > Okay. I suggest: > > The enveloped-data content type is ASN.1 encoded using the > EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be > populated as described in Section 6 of [CMS]. The RecipientInfo > choice is described in Section 6.2 of [CMS], and repeated here for > convenience. > > RecipientInfo ::=3D CHOICE { > ktri KeyTransRecipientInfo, > kari [1] KeyAgreeRecipientInfo, > kekri [2] KEKRecipientInfo, > pwri [3] PasswordRecipientinfo, > ori [4] OtherRecipientInfo } > > For the recipients that use X25519 or X448 the RecipientInfo kari > choice MUST be used. > This would be fine. -Ekr > > Russ > > --001a114174689da2bc054f1b01b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 9:03 AM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
I dropped the parts that have been resolved.

> TECHNICAL
> S 2.
>=C2=A0 =C2=A0 X25519 is described in Section 6.1 of [CURVES], and X448 = is described
>=C2=A0 =C2=A0 in Section 6.2 of [CURVES].=C2=A0 Since curve25519 and cu= rve448 have
>=C2=A0 =C2=A0 cofactors of 8 and 4, respectively, an input point of sma= ll order
>=C2=A0 =C2=A0 will eliminate any contribution from the other party=E2= =80=99s private key.
>=C2=A0 =C2=A0 As described in Section 7 of [CURVES], implementations SH= OULD detect
>=C2=A0 =C2=A0 this situation by checking for the all-zero output.
>
> Why are you not requiring this check? SSH and TLS both do.

RFC 7748 [CURVES] says:

=C2=A0 =C2=A0Protocol designers using Diffie-Hellman over the curves define= d in
=C2=A0 =C2=A0this document must not assume "contributory behaviour&quo= t;.=C2=A0 Specially,
=C2=A0 =C2=A0contributory behaviour means that both parties' private ke= ys
=C2=A0 =C2=A0contribute to the resulting shared key.=C2=A0 Since curve25519= and
=C2=A0 =C2=A0curve448 have cofactors of 8 and 4 (respectively), an input po= int of
=C2=A0 =C2=A0small order will eliminate any contribution from the oth= er party's
=C2=A0 =C2=A0private key.=C2=A0 This situation can be detected by ch= ecking for the all-
=C2=A0 =C2=A0zero output, which implementations MAY do, as specified in Sec= tion 6.
=C2=A0 =C2=A0However, a large number of existing implementations do not do = this.

We upgraded the MAY to a SHOULD.=C2=A0 We are being told that some implemen= tations will not perform this check, so it seemed wrong to go all the way t= o MUST.

I'd like to push on this so= me, because I'm having trouble seeing why different IETF protocols have= different needs. When you say "you are being told" is that an S/= MIME specific point or merely the the text above?

The text above, which I gather is about so= me existing implementations, probably libraries.=C2=A0 I do not know what p= rotocols use those implementations, but if they are libraries they will get= used with many different protocols.

Sure, but other protocols are requiring it and it seems like S/MIME c= ould also do so, in
the worst case at the point where Z is handed= off to S/MIME.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 The ECC-CMS-SharedInfo entityUInfo field optionally conta= ins
>=C2=A0 =C2=A0 additional keying material supplied by the sending agent.= =C2=A0 Note that
>=C2=A0 =C2=A0 [CMS] requires implementations to accept a KeyAgreeRecipi= entInfo
>=C2=A0 =C2=A0 SEQUENCE that includes the ukm field.=C2=A0 If the ukm fi= eld is present,
>=C2=A0 =C2=A0 the ukm is placed in the entityUInfo field.=C2=A0 The ukm= value need not
>=C2=A0 =C2=A0 be longer than the key-encryption key that will be produc= ed by the
>=C2=A0 =C2=A0 KDF.
>
> Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness?

I suggest this wording:

=C2=A0 =C2=A0=E2=80=A6 There is no security benefit to using a ukm value th= at is
=C2=A0 =C2=A0longer than the key-encryption key that will be produced= by
=C2=A0 =C2=A0the KDF.

Hmm... I b= elieve that this statement is true, but it also seems to be
incom= plete. I may be reasoning about this incorrectly, but it seems
to= me that the minimal security requirement is that the UKM be
uniq= ue, but that can be achieved with a value much smaller than
the K= EK. For instance, it seems like if you have a 256-bit KEK,
then y= ou would still be OK with a randomly-generated 128-bit
UKM. And i= f we're concerned about random collisions, then the
usefulnes= s bound is actually min(|KEK|, |hash compression function size|).

Yes. The umm value needs t= o be different for each invocation of the KDF, otherwise it does not provid= e the assurance that different keying material will be produced.=C2=A0 Of c= ourse, an implementation will generate the umm value using random number ge= nerator, not track the values that are used.=C2=A0 Several years ago, there= was a discussion about the size of the ukm needed.=C2=A0 Some people were = suggesting crazy large values, and the point was made that anything beyond = the SIZEOF(KEK) did not improve security.

Are you = asking for a sentence saying that the ukm, if present, MUST be at least 128= bits?

Sorry, I was trying to t= alk it over, but I'm not sure how helpful I am being. It seems like the= basic requirement is that it be unique and that if we want to give guidanc= e it should be on the collision probability. Do we believe that 128 bits is= enough (I do!), in which case we can just say "if you are generating = it randomly, then N bits is enough"

=
> S 9.
> This section is kinda diffident about whether the sender's
> ephemeral is truly ephemeral. Is this a MUST? If so, please
> say so.

Section 2 already explains that the originator uses an ephemeral key= pair.

Yes, but it doesn't have any= normative language (see above on this topic).

I see.=C2=A0 I=E2=80=99ll reword the text in = Section 2 to use MUST.

How about:

=C2=A0 =C2=A0The originator MUST use an ephemeral public/priv= ate key pair that is
=C2=A0 =C2=A0generated on the same elliptic = curve as the public key of the
=C2=A0 =C2=A0recipient.=C2=A0 The = ephemeral key pair MUST be used for a single CMS
=C2=A0 =C2=A0pro= tected content type, and then it MUST be discarded.=C2=A0 The
=C2= =A0 =C2=A0originator obtains the recipient's static public key from the=
=C2=A0 =C2=A0recipient's certificate [PROFILE].
<= /div>

LGTM.
=C2=A0



Russ


--001a114174689da2bc054f1b01b8-- From nobody Tue May 9 11:08:28 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7710312952D for ; Tue, 9 May 2017 11:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Oe0pmtyxWPL for ; Tue, 9 May 2017 11:08:23 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BB91292FC for ; Tue, 9 May 2017 11:08:23 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 8so2314885ybw.1 for ; Tue, 09 May 2017 11:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tSDmUDOP86dBj3vProxhmJRAKnU4n6Ev9IS+ISwqo2s=; b=tOE8aXLOBtd1qrkJA6xSVVnxMEAwKkrcASfjBEWzjarg5h/iCI8qAl0+Emq9V/lCQO PUv9lsyGEj6c9HKt0I/XDi+CuNMaQBoUIYN5w4ZrnWEjJAC+C9p+fxDaOPppmMnpZg/Y aNPOGqZ0+EvyoKLc9Hi9rEO+yhrdCs0pXef+RDxkV7OtXTfV7bELp5SG6Jcyw5fX8bw9 guchX70cHn5+raayDz3xnOq0G3CYVhh5U6cRN7wbLCeQ5UY6V+XexiToKzkOE75I/L0I vPILka3wmIv8D/+7XDc+ZF0LLL7HmnZxLrJ3VDYKouXmnsIbWwnj/UpjaNZcVxNh7gSZ x1bA== 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=tSDmUDOP86dBj3vProxhmJRAKnU4n6Ev9IS+ISwqo2s=; b=kNQ/qAtUWsh5oJc9sD73ZlY6pNXhTJLfWgN0QlgP2N35vQrBAVQu/4Bj0cpcG3IMFb nDstUFG/6Mi63iyhLZCqHBHktThb6dRWyN3od3m+Dy2WuwEqP5aweOoojrBWkvfrVT2J 3xK2fNNjCOT/z3RI1aDidoqCoNKYtU3oXquRbvT8h9FtWtSBIng6E7ir6HUKhqpFS+2a rZTh5OVSrd8bpWr969jhMw8JasYMJ0mfHM0Ft6JhOiIXP4eUM8Y0OwrWRpA3Nkw3I+zB zJ1sACx2wHO8LhgAoG3qEcRAW+K/lktSSDdzhUcKscHiMStJWYuuMPqCPYx6tUlJvu/P 0nRw== X-Gm-Message-State: AODbwcDm3GHOU/ieeH1WHJ1av0QOdQ0xH+gg3Lr1tpXokoORLBWmkIBP L513j5HPuJtqWzL1ajH/Wm2MzvKHU/I3 X-Received: by 10.37.161.196 with SMTP id a62mr1324725ybi.9.1494353302797; Tue, 09 May 2017 11:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 9 May 2017 11:07:42 -0700 (PDT) In-Reply-To: <20170509055301.GB30306@kduck.kaduk.org> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> From: Eric Rescorla Date: Tue, 9 May 2017 11:07:42 -0700 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , Jim Schaad , curdle Content-Type: multipart/alternative; boundary=f403045c5632c8f1da054f1b3d4f Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:08:25 -0000 --f403045c5632c8f1da054f1b3d4f Content-Type: text/plain; charset=UTF-8 Speaking as AD, I am trying to minimize AD sponsorship, especially when there is an existing group. Therefore, I would favor the WG process in this case. -Ekr On Mon, May 8, 2017 at 10:53 PM, Benjamin Kaduk wrote: > On Tue, May 09, 2017 at 03:26:59PM +1000, Martin Thomson wrote: > > On 9 May 2017 at 15:10, Benjamin Kaduk wrote: > > > It's uncontroversial and the AD-sponsored path might shave a couple > > > weeks off it? > > > > > > I'm pushing back on this pattern when I see it. AD sponsorship puts > > more work on an individual; the same goes for publication on the > > independent stream. > > You asked for "any reason", not "any good reason" :-P > You're right to push back on it... > > > If there is a problem with the efficiency of working groups, using > > these alternative routes lets the problem fester. I suspect that - > > more often than not - the problem is lack of energy or lack of > > consensus. > > Lots of lack of energy in places I frequent, alas. > > -Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045c5632c8f1da054f1b3d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking as AD, I am trying to minimize AD sponsorship, es= pecially when there is an existing group. Therefore, I would favor the WG p= rocess in this case.

-Ekr


On Mon, May 8, 2017 a= t 10:53 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Tue, May 09, 2017 at 03:26:59PM +10= 00, Martin Thomson wrote:
> On 9 May 2017 at 15:10, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > It's uncontroversial and the AD-sponsored path might shave a = couple
> > weeks off it?
>
>
> I'm pushing back on this pattern when I see it.=C2=A0 AD sponsorsh= ip puts
> more work on an individual; the same goes for publication on the
> independent stream.

You asked for "any reason", not "any good reason"= ; :-P
You're right to push back on it...

> If there is a problem with the efficiency of working groups, using
> these alternative routes lets the problem fester. I suspect that -
> more often than not - the problem is lack of energy or lack of
> consensus.

Lots of lack of energy in places I frequent, alas.

-Ben

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

--f403045c5632c8f1da054f1b3d4f-- From nobody Tue May 9 11:35: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 E0ECD129BA2 for ; Tue, 9 May 2017 11:35:06 -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 My_YZM32TBa9 for ; Tue, 9 May 2017 11:35:05 -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 A5CAD12762F for ; Tue, 9 May 2017 11:35:05 -0700 (PDT) X-AuditID: c618062d-469ff70000000cf0-de-59121f06d903 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.8B.03312.60F12195; Tue, 9 May 2017 21:56:56 +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, 9 May 2017 14:35:02 -0400 From: Daniel Migault To: Eric Rescorla , Benjamin Kaduk CC: Jim Schaad , Martin Thomson , curdle Thread-Topic: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9Dmpp6H9l8iQgACcjgCAAGm8AIAABJiAgAAHRoCAAM1FAP//whag Date: Tue, 9 May 2017 18:35:02 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> 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.10] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXRPgi6HvFCkwcJHIhZbF85itljx+hy7 xerp39kslm+cyWRx7cw/RgdWj41zprN57Jx1l91jyZKfTB5NZ44ye0x+3MYcwBrFZZOSmpNZ llqkb5fAlbF15VKWgllqFV8uPGBpYOxQ7WLk5JAQMJGYuWYtexcjF4eQwFFGict3tkE5yxgl unZtYwapYhMwkmg71M8OYosIOEisOHeUBcRmFsiTWPL3NyOILSyQIHH+3wYmiJpEiRk/f7JB 2FESyx4fYwWxWQRUJJ49nAoW5xXwldi1tIkVYtl6ZonVi9aBDeUUCJTY2XAYbBCjgJjE91Nr mCCWiUvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRny+xZ1cfE8QyQYmTM5+wTGAU mYVk1CwkZbOQlM1i5ACKa0qs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYwcpcUFObnpRgab GIGxd0yCTXcH4/3pnocYBTgYlXh4FzALRQqxJpYVV+YeYpTgYFYS4Y0GCfGmJFZWpRblxxeV 5qQWH2KU5mBREuedcP5ChJBAemJJanZqakFqEUyWiYNTqoGR4+F+d9/vdrV9d+fLK8/WDj9a 8zBznpWSeeMlk9vZafWLavm6FuYe+NzxYVpKUPjTVRpHPx5+mGgx85rYAz+1qVda721ftNK1 z+e65vMvs3y2cVhlbYmTtnsn8mzP1YPqjpm/GePlI18eXTZHY8986RBud9kUtjpu7U7d847a PUdf5DG/XmOrxFKckWioxVxUnAgACKgO17kCAAA= Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:35:07 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgZm9sbG93aW5nIGRyYWZ0 OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2hhYWQtY3VyZGxlLW9p ZC1yZWdpc3RyeS8NCg0KSWYgeW91IGJlbGlldmUgdGhpcyBkcmFmdCBzaG91bGQgbm90IGJlIGFk b3B0ZWQgYXMgYSBXRyBkb2N1bWVudCBwbGVhc2UgbGV0IHVzIGtub3cgYnkgTWF5IDIzLg0KUGxl YXNlIGFsc28gcHJvdmlkZSB5b3VyIHJldmlld3Mgb2YgdGhlIGRyYWZ0Lg0KDQpZb3VycywNCkRh bmllbA0KDQo= --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5IaSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIGEgY2FsbCBmb3IgYWRv cHRpb24gb2YgdGhlIGZvbGxvd2luZyBkcmFmdDoNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2hhYWQtY3VyZGxlLW9pZC1yZWdpc3RyeS8i Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaGFhZC1jdXJkbGUtb2lk LXJlZ2lzdHJ5LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGJlbGlldmUgdGhp cyBkcmFmdCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSBXRyBkb2N1bWVudCBwbGVhc2UgbGV0 IHVzIGtub3cgYnkgTWF5IDIzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QbGVhc2UgYWxzbyBwcm92aWRlIHlvdXIgcmV2aWV3cyBvZiB0aGUgZHJhZnQuIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3VycywgPGJyPg0KRGFuaWVsIDxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66eusaamb107erics_-- From nobody Tue May 9 12:13: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 0E7B7129789 for ; Tue, 9 May 2017 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXwejd6TrXLb for ; Tue, 9 May 2017 12:13:10 -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 399FA12EADA for ; Tue, 9 May 2017 12:13:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01D2C8BD.A3ABB8C0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494357186; h=from:subject:to:date:message-id; bh=kXVS+/MWfNVO1uOyN5CDf3LCy9Eb/Iqcs5HI+cKexJU=; b=JZgRNZkWAzYN5DeRkBnoA7NcdBCuGmrBAfnj/GHekAnYwd55beGJMqRhzZmPHdglWj1ILHw8TaI CHpyHGXX0TZkNCVlkGd5DhkI+c+t5RZih0iwo5CPxnwqTMAUWjdYO/oIn4UdPK6DFVhOa0Dy7sVur YXMNpfXEdEk0kjNbJYLDlOAxpdb7KxfWUn+7DeCxBJAtUC1kr27ooYaKvatCffYEo73E5ubQsgeeZ jmmDKnc93p/MfLhDKy+LKpddRsPUVYFS9a95aTCUeQiH9s/DzkAX3mzMjWGDIwyKP0yh9uSFB9y6v c6z2PHugbbot3oZOCVmj2ivfpAIGqiLxVfoA== 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, 9 May 2017 12:13:06 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 12:12:53 -0700 From: Jim Schaad To: 'Daniel Migault' , 'Eric Rescorla' , 'Benjamin Kaduk' CC: 'Martin Thomson' , 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> Date: Tue, 9 May 2017 12:13:13 -0700 Message-ID: <015101d2c8f8$5009cd70$f01d6850$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAWt1TpUBWsHjHAN7FOQdAZi7CHQBRXVEwwHSbWjqoZYANbA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] : RE: FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 19:13:12 -0000 ------=_NextPart_000_0152_01D2C8BD.A3ABB8C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If EKR says do it here, then I support adoption. =20 From: Daniel Migault [mailto:daniel.migault@ericsson.com]=20 Sent: Tuesday, May 9, 2017 11:35 AM To: Eric Rescorla ; Benjamin Kaduk Cc: Jim Schaad ; Martin Thomson = ; curdle Subject: : RE: [Curdle] FW: New Version Notification for = draft-schaad-curdle-oid-registry-00.txt =20 Hi,=20 =20 This is a call for adoption of the following draft: = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ =20 If you believe this draft should not be adopted as a WG document please = let us know by May 23.=20 Please also provide your reviews of the draft.=20 =20 Yours,=20 Daniel=20 =20 ------=_NextPart_000_0152_01D2C8BD.A3ABB8C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If EKR says = do it here, then I support adoption.

 

From:<= /b> = Daniel Migault [mailto:daniel.migault@ericsson.com]
Sent: = Tuesday, May 9, 2017 11:35 AM
To: Eric Rescorla = <ekr@rtfm.com>; Benjamin Kaduk <kaduk@mit.edu>
Cc: = Jim Schaad <ietf@augustcellars.com>; Martin Thomson = <martin.thomson@gmail.com>; curdle = <curdle@ietf.org>
Subject: <BULK>: RE: [Curdle] = FW: New Version Notification for = draft-schaad-curdle-oid-registry-00.txt

=

 

Hi, =

 

This is a = call for adoption of the following draft: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/=

 

If you believe this draft should not be adopted as a = WG document please let us know by May 23.

Please also provide your reviews of the draft. =

 

Yours,
Daniel

 

------=_NextPart_000_0152_01D2C8BD.A3ABB8C0-- From nobody Tue May 9 12:14: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 49E5012EADE for ; Tue, 9 May 2017 12:14:55 -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 qFKC-c9b7ytW for ; Tue, 9 May 2017 12:14:53 -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 987A112EADA for ; Tue, 9 May 2017 12:14:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v49JBttU014802 for ; Tue, 9 May 2017 20:14:51 +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=FxCaoEwGk8yVcDLDr0eHVCakDojIiRQpDeuFNyGNFJQ=; b=PHBwv9OOig7k2Or+Xj3txXUl8thHYyJMMTPujnrb3Tu3vzgpZIDGvnx1F6Wb90t+zuy2 1/MPnVELmmt7U3nUqtTC3ML2zoubGSp28f+N0X7SsBKfXQ2pka5nmQNh62WEuxJuEb8V kyBiEbLTl7JqkXDDwAuNN9KCSIYKMvQ1MNTQzE8s5rkjPE4+vh3oX7QEZjhAQETUqC16 QA9p/SzvTrCCRIDrW2RcZacnZVQPIM4d8C/kQ8/bOR+vjNY93SmqViL+NHm+7Z0pUWaP +uZHHEhpqq9BP/e62rffDjV87NFJvHGj+F9IP0HCa68ijzRIiQSIsL6UXI8vEeSoAjaZ mQ== 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 2abcamjune-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 20:14:51 +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 v49JBHeF024728 for ; Tue, 9 May 2017 15:14:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a99tuntfk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 15:14:50 -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.1263.5; Tue, 9 May 2017 15:14:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 9 May 2017 15:14:49 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: [Curdle] : RE: FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt Thread-Index: AQHSyPhRicwubwedQ0uwEnjVTuj9O6HsXsbQ Date: Tue, 9 May 2017 19:14:49 +0000 Message-ID: <27cfc52170fa4798935921c3f6dc3597@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <015101d2c8f8$5009cd70$f01d6850$@augustcellars.com> In-Reply-To: <015101d2c8f8$5009cd70$f01d6850$@augustcellars.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.36.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090107 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090107 Archived-At: Subject: Re: [Curdle] : RE: FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 19:14:55 -0000 PiBJZiBFS1Igc2F5cyBkbyBpdCBoZXJlLCB0aGVuIEkgc3VwcG9ydCBhZG9wdGlvbi4NCg0KRG9l cyBhbnlvbmUgaGF2ZSBmZWVsaW5ncyBhZ2FpbnN0IGFkb3B0aW5nIHRoaXM/ICBQbGVhc2Ugc3Bl YWsgdXAgc29vbi4NCg== From nobody Tue May 9 12:36:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F29C12EAF3 for ; Tue, 9 May 2017 12:36:31 -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 fjKZ6auGmltg for ; Tue, 9 May 2017 12:36:29 -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 3A7AD12EAE4 for ; Tue, 9 May 2017 12:36:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9EA703004DB for ; Tue, 9 May 2017 15:36:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vDJzu4DqnxIM for ; Tue, 9 May 2017 15:36:24 -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 C6D0B3004D8; Tue, 9 May 2017 15:36:23 -0400 (EDT) From: Russ Housley Message-Id: <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CA4B4577-F090-4459-8C19-7240BEC72B9F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 15:36:26 -0400 In-Reply-To: <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> Cc: Eric Rescorla , curdle To: Jim Schaad References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 19:36:31 -0000 --Apple-Mail=_CA4B4577-F090-4459-8C19-7240BEC72B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 9, 2017, at 1:47 PM, Jim Schaad wrote: >=20 > See inline. > =20 > From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Russ Housley > Sent: Tuesday, May 9, 2017 9:04 AM > To: Eric Rescorla > > Cc: curdle > > Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt > =20 > I dropped the parts that have been resolved. >=20 >=20 >>> > TECHNICAL >>> > S 2. >>> > X25519 is described in Section 6.1 of [CURVES], and X448 is = described >>> > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. >>> > As described in Section 7 of [CURVES], implementations SHOULD = detect >>> > this situation by checking for the all-zero output. >>> > >>> > Why are you not requiring this check? SSH and TLS both do. >>>=20 >>> RFC 7748 [CURVES] says: >>>=20 >>> 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. >>>=20 >>> We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. >> =20 >> I'd like to push on this some, because I'm having trouble seeing why = different IETF protocols have different needs. When you say "you are = being told" is that an S/MIME specific point or merely the the text = above? > =20 > The text above, which I gather is about some existing implementations, = probably libraries. I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols. > =20 > [JLS] As I have stated in the past =E2=80=93 I am with EKR on this. Previously, only Jim had posted in support for this check. I will = change the SHOULD to a MUST. >=20 >>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>> > additional keying material supplied by the sending agent. Note = that >>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>> > the ukm is placed in the entityUInfo field. The ukm value need = not >>> > be longer than the key-encryption key that will be produced by = the >>> > KDF. >>> > >>> > Need not? Please clarify what the purpose is here. It seems like >>> > it's to generate a unique KEK. In that case, the security bounds >>> > are what, uniqueness? >>>=20 >>> I suggest this wording: >>>=20 >>> =E2=80=A6 There is no security benefit to using a ukm value that = is >>> longer than the key-encryption key that will be produced by >>> the KDF. >> =20 >> Hmm... I believe that this statement is true, but it also seems to be >> incomplete. I may be reasoning about this incorrectly, but it seems >> to me that the minimal security requirement is that the UKM be >> unique, but that can be achieved with a value much smaller than >> the KEK. For instance, it seems like if you have a 256-bit KEK, >> then you would still be OK with a randomly-generated 128-bit >> UKM. And if we're concerned about random collisions, then the >> usefulness bound is actually min(|KEK|, |hash compression function = size|). > =20 > Yes. The umm value needs to be different for each invocation of the = KDF, otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. > =20 > Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? > =20 > [JLS] I would disagree that the value has to be random, a counter will = work as well. (An encrypted counter is better.) I not be happy with a = fixed size requirement on this easier. There is no reason to make such = a requirement that I can think of. A 64-bit counter is just as = rational. It might make more sense to change this statement into = something along the lines of=20 > =20 > * Any pair of static keys MUST NOT be used more times than the size of = the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on the number of times the key pair can be used. > * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. Section 2 already says that the ephemeral key MUST be used for only one = message. Thus, a UKM is not really needed. However, the CMS requires = support for a UKM if the sender include it. For this reason, the = document says how to handle it in the KDF if it is present. You are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. The text already says that there is no security reason for a UKM value = that is longer than the KEK. I think that EKR is asking for guidance on = the minimum size too. Russ --Apple-Mail=_CA4B4577-F090-4459-8C19-7240BEC72B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 9, 2017, at 1:47 PM, Jim Schaad <ietf@augustcellars.com> wrote:

See inline.
 
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf = Of Russ Housley
Sent: Tuesday, May 9, 2017 9:04 = AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: curdle <curdle@ietf.org>
Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt
 
I dropped the parts that have been = resolved.


> = TECHNICAL
> S 2.
>    X25519 = is described in Section 6.1 of [CURVES], and X448 is described
>    in Section 6.2 of [CURVES].  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=E2=80=99s private key.
>    As = described in Section 7 of [CURVES], implementations SHOULD detect
>    this situation by checking for the all-zero = output.
>
> Why are you not requiring = this check? SSH and TLS both do.

RFC 7748 = [CURVES] says:

   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.

We upgraded = the MAY to a SHOULD.  We are being told that some implementations = will not perform this check, so it seemed wrong to go all the way to = MUST.
 
I'd like to push on this some, because I'm having trouble = seeing why different IETF protocols have different needs. When you say = "you are being told" is that an S/MIME specific point or merely the the = text above?
 
The text above, which I gather is about some existing = implementations, probably libraries.  I do not know what protocols = use those implementations, but if they are libraries they will get used = with many different protocols.
 
[JLS] As = I have stated in the past =E2=80=93 I am with EKR on this.

Previously, only Jim had posted in support for this = check.  I will change the SHOULD to a MUST.


>  =   The ECC-CMS-SharedInfo entityUInfo field optionally contains
>    additional keying material supplied by the = sending agent.  Note that
>    [CMS] = requires implementations to accept a KeyAgreeRecipientInfo
>    SEQUENCE that includes the ukm field.  = If the ukm field is present,
>    the ukm is = placed in the entityUInfo field.  The ukm value need not
>    be longer than the key-encryption key that = will be produced by the
>    KDF.
>
> Need not? Please clarify what the = purpose is here. It seems like
> it's to generate a = unique KEK. In that case, the security bounds
> are = what, uniqueness?

I suggest this = wording:

   =E2=80=A6 There is no = security benefit to using a ukm value that is
  =  longer than the key-encryption key that will be produced by
   the KDF.
 
Hmm... I believe that this statement is = true, but it also seems to be
incomplete. I may be = reasoning about this incorrectly, but it seems
to me that the minimal security requirement is that the UKM = be
unique, but that can be achieved with a value much smaller = than
the KEK. For instance, it seems like if = you have a 256-bit KEK,
then you would still be OK = with a randomly-generated 128-bit
UKM. And if we're = concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression = function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are you asking for a sentence saying = that the ukm, if present, MUST be at least 128 bits?
 
[JLS] I would disagree that the value has to be = random, a counter will work as well.  (An encrypted counter is = better.)  I not be happy with a fixed size requirement on this = easier.  There is no reason to make such a requirement that I can = think of.  A 64-bit counter is just as rational.  It might = make more sense to change this statement into something along the lines = of 
 
* Any = pair of static keys MUST NOT be used more times than the size of the = key.  I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on the number of times the key pair can be used.
* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any event.

Section 2 already says that the ephemeral key MUST be = used for only one message.  Thus, a UKM is not really needed. =  However, the CMS requires support for a UKM if the sender include = it.  For this reason, the document says how to handle it in the KDF = if it is present.

You are correct = that a counter, encrypted counter, or random value will work, even if = the originator uses the same ephemeral key for many messages.  The = text does not limit the choices in any way.

The text already says that there is no security = reason for a UKM value that is longer than the KEK.  I think that = EKR is asking for guidance on the minimum size too.

Russ

= --Apple-Mail=_CA4B4577-F090-4459-8C19-7240BEC72B9F-- From nobody Tue May 9 13:06: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 DF3AD1296D2 for ; Tue, 9 May 2017 13:06:52 -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 WfeExl35FM9d for ; Tue, 9 May 2017 13:06:46 -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 E45A9129BD4 for ; Tue, 9 May 2017 13:06:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5D406300523 for ; Tue, 9 May 2017 16:06:45 -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 Ga6Ebp98edDo for ; Tue, 9 May 2017 16:06: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 69E8530024B; Tue, 9 May 2017 16:06:42 -0400 (EDT) From: Russ Housley Message-Id: <335FDBE0-96B5-4DCC-BED9-4ABD5DAB371A@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B28E1F-145A-44E3-8B4A-5E0DD1EA3B6C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 16:06:45 -0400 In-Reply-To: Cc: curdle To: Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 20:06:53 -0000 --Apple-Mail=_D4B28E1F-145A-44E3-8B4A-5E0DD1EA3B6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 9, 2017, at 1:50 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, May 9, 2017 at 9:03 AM, Russ Housley > wrote: > I dropped the parts that have been resolved. >=20 >> > TECHNICAL >> > S 2. >> > X25519 is described in Section 6.1 of [CURVES], and X448 is = described >> > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. >> > As described in Section 7 of [CURVES], implementations SHOULD = detect >> > this situation by checking for the all-zero output. >> > >> > Why are you not requiring this check? SSH and TLS both do. >>=20 >> RFC 7748 [CURVES] says: >>=20 >> 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. >>=20 >> We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. >>=20 >> I'd like to push on this some, because I'm having trouble seeing why = different IETF protocols have different needs. When you say "you are = being told" is that an S/MIME specific point or merely the the text = above? >=20 > The text above, which I gather is about some existing implementations, = probably libraries. I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols. >=20 > Sure, but other protocols are requiring it and it seems like S/MIME = could also do so, in > the worst case at the point where Z is handed off to S/MIME.=20 I suggest: X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. As described in Section 7 of [CURVES], curve25519 and curve448 have cofactors of 8 and 4, respectively, and so an input point of small order will eliminate any contribution from the other party's private key. Conforming implementations MUST check for the all-zero output to prevent this situation. >> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >> > additional keying material supplied by the sending agent. Note = that >> > [CMS] requires implementations to accept a KeyAgreeRecipientInfo >> > SEQUENCE that includes the ukm field. If the ukm field is = present, >> > the ukm is placed in the entityUInfo field. The ukm value need = not >> > be longer than the key-encryption key that will be produced by = the >> > KDF. >> > >> > Need not? Please clarify what the purpose is here. It seems like >> > it's to generate a unique KEK. In that case, the security bounds >> > are what, uniqueness? >>=20 >> I suggest this wording: >>=20 >> =E2=80=A6 There is no security benefit to using a ukm value that = is >> longer than the key-encryption key that will be produced by >> the KDF. >>=20 >> Hmm... I believe that this statement is true, but it also seems to be >> incomplete. I may be reasoning about this incorrectly, but it seems >> to me that the minimal security requirement is that the UKM be >> unique, but that can be achieved with a value much smaller than >> the KEK. For instance, it seems like if you have a 256-bit KEK, >> then you would still be OK with a randomly-generated 128-bit >> UKM. And if we're concerned about random collisions, then the >> usefulness bound is actually min(|KEK|, |hash compression function = size|). >=20 > Yes. The umm value needs to be different for each invocation of the = KDF, otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. >=20 > Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? >=20 > Sorry, I was trying to talk it over, but I'm not sure how helpful I am = being. It seems like the basic requirement is that it be unique and that = if we want to give guidance it should be on the collision probability. = Do we believe that 128 bits is enough (I do!), in which case we can just = say "if you are generating it randomly, then N bits is enough=E2=80=9D Jim is correct that counters, encrypted counters, linear feedback shift = registers, and other techniques will work here too. Since Section 2 already says that the ephemeral key MUST be used for = only one message, a UKM is not really needed. However, the CMS requires = support for a UKM if the sender include it. For this reason, the = document says how to handle it in the KDF if it is present. The text already says that there is no security reason for a UKM value = that is longer than the KEK. I think that you are asking for guidance = on the minimum size too. Based on Jim=E2=80=99s point, I=E2=80=99d like = to say that it MUST be at least 8 octets. Russ --Apple-Mail=_D4B28E1F-145A-44E3-8B4A-5E0DD1EA3B6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 9, 2017, at 1:50 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Tue, May 9, 2017 at 9:03 AM, = Russ Housley <housley@vigilsec.com> wrote:
I dropped the = parts that have been resolved.

> TECHNICAL
> S 2.
>    X25519 is described in Section 6.1 of [CURVES], and = X448 is described
>    in Section 6.2 of [CURVES].  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=E2=80=99s private key.
>    As described in Section 7 of [CURVES], implementations = SHOULD detect
>    this situation by checking for the all-zero output.
>
> Why are you not requiring this check? SSH and TLS both do.

RFC 7748 [CURVES] says:

   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.

We upgraded the MAY to a SHOULD.  We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST.

I'd like to push on this some, because = I'm having trouble seeing why different IETF protocols have different = needs. When you say "you are being told" is that an S/MIME specific = point or merely the the text = above?

The text above, which I gather is about some = existing implementations, probably libraries.  I do not know what = protocols use those implementations, but if they are libraries they will = get used with many different protocols.

Sure, but other = protocols are requiring it and it seems like S/MIME could also do so, = in
the worst case at the point where Z is handed = off to S/MIME. 

I suggest:

   X25519 is described in Section = 6.1 of [CURVES], and X448 is described
   in Section = 6.2 of [CURVES].  As described in Section 7 of = [CURVES],
   curve25519 and curve448 have cofactors = of 8 and 4, respectively, and
   so an input point = of small order will eliminate any contribution from
  =  the other party's private key.  Conforming implementations = MUST check
   for the all-zero output to prevent = this situation.


>    The ECC-CMS-SharedInfo entityUInfo field optionally = contains
>    additional keying material supplied by the sending = agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that includes the ukm field.  If the ukm = field is present,
>    the ukm is placed in the entityUInfo field.  The = ukm value need not
>    be longer than the key-encryption key that will be = produced by the
>    KDF.
>
> Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the security bounds
> are what, uniqueness?

I suggest this wording:

   =E2=80=A6 There is no security benefit to using a ukm value = that is
   longer than the key-encryption key that = will be produced by
   the KDF.

Hmm... I believe that = this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me that the minimal security requirement = is that the UKM be
unique, but that can be achieved = with a value much smaller than
the KEK. For = instance, it seems like if you have a 256-bit KEK,
then you would still be OK with a randomly-generated = 128-bit
UKM. And if we're concerned about random = collisions, then the
usefulness bound is actually = min(|KEK|, |hash compression function = size|).

Yes. The umm value needs to be different for = each invocation of the KDF, otherwise it does not provide the assurance = that different keying material will be produced.  Of course, an = implementation will generate the umm value using random number = generator, not track the values that are used.  Several years ago, = there was a discussion about the size of the ukm needed.  Some = people were suggesting crazy large values, and the point was made that = anything beyond the SIZEOF(KEK) did not improve security.

Are you asking for a = sentence saying that the ukm, if present, MUST be at least 128 = bits?

Sorry, I was trying to talk it over, but I'm not sure how = helpful I am being. It seems like the basic requirement is that it be = unique and that if we want to give guidance it should be on the = collision probability. Do we believe that 128 bits is enough (I do!), in = which case we can just say "if you are generating it randomly, then N = bits is enough=E2=80=9D

Jim is correct that counters, encrypted counters, = linear feedback shift registers, and other techniques will work here = too.

Since Section 2 = already says that the ephemeral key MUST be used for only one message, a = UKM is not really needed.  However, the CMS requires support for a = UKM if the sender include it.  For this reason, the document says = how to handle it in the KDF if it is present.

The text already says that there is no = security reason for a UKM value that is longer than the KEK.  I = think that you are asking for guidance on the minimum size too. =  Based on Jim=E2=80=99s point, I=E2=80=99d like to say that it MUST = be at least 8 octets.

Russ

= --Apple-Mail=_D4B28E1F-145A-44E3-8B4A-5E0DD1EA3B6C-- From nobody Tue May 9 13:18: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 81AF612EAF7 for ; Tue, 9 May 2017 13:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upd-oupVldV1 for ; Tue, 9 May 2017 13:18:01 -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 9C75512932A for ; Tue, 9 May 2017 13:18:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0169_01D2C8C6.B1CE41D0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494361077; h=from:subject:to:date:message-id; bh=nCAmqRAX0fZtEHx63mODlQ1kubkQTaj6Q2FrZH/m5aw=; b=kCF57TyaKJVyDJQvMLoGE5s2GOBFCSeknUUUR1zV+NjtJCmrHufq3CZbDMmRDYZE3egwUcMNOVx jkHl9ANTvbbH9o3iFmiFzQjlqxGsrxZZySL6YCvxTF6mbNKvXj6y8c9fm8oyx3WmdP7s8dsk3p934 UJ0waS5/z4GgzLYsLvFK1EZ54KolIzGhCtIsnqHAmH+dFq2e0H2egFIzPsLCtltdAlNDaIoINZ6QB W67gwlazrShB3A/85yhpvuXsyjn868gRTpikKQZeYwC+0Svg4PkGKlvVs6sfSzOW80aNc+nX/qRiV iO/wL0ye5ouJ3rmdOfpCadzVjUYYoG7oFXmA== 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, 9 May 2017 13:17:55 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 13:17:43 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'Eric Rescorla' , 'curdle' References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> In-Reply-To: <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> Date: Tue, 9 May 2017 13:18:03 -0700 Message-ID: <016801d2c901$5e299760$1a7cc620$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH9xBMcsIwTVYthAE2k4UvXwpKedQIe2gLjAVvwxw4CXdRt+QMS7ygCAmXEUp6hO+1AgA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 20:18:05 -0000 ------=_NextPart_000_0169_01D2C8C6.B1CE41D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Tuesday, May 9, 2017 12:36 PM To: Jim Schaad Cc: Eric Rescorla ; curdle Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt =20 =20 On May 9, 2017, at 1:47 PM, Jim Schaad > wrote: =20 See inline. =20 From: Curdle [ = mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, May 9, 2017 9:04 AM To: Eric Rescorla < ekr@rtfm.com> Cc: curdle < curdle@ietf.org> Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt =20 I dropped the parts that have been resolved. > TECHNICAL > S 2. > X25519 is described in Section 6.1 of [CURVES], and X448 is = described > in Section 6.2 of [CURVES]. 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=E2=80=99s = private key. > As described in Section 7 of [CURVES], implementations SHOULD = detect > this situation by checking for the all-zero output. > > Why are you not requiring this check? SSH and TLS both do. RFC 7748 [CURVES] says: 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. We upgraded the MAY to a SHOULD. We are being told that some = implementations will not perform this check, so it seemed wrong to go = all the way to MUST. =20 I'd like to push on this some, because I'm having trouble seeing why = different IETF protocols have different needs. When you say "you are = being told" is that an S/MIME specific point or merely the the text = above? =20 The text above, which I gather is about some existing implementations, = probably libraries. I do not know what protocols use those = implementations, but if they are libraries they will get used with many = different protocols. =20 [JLS] As I have stated in the past =E2=80=93 I am with EKR on this. =20 Previously, only Jim had posted in support for this check. I will = change the SHOULD to a MUST. > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note = that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. The ukm value need not > be longer than the key-encryption key that will be produced by the > KDF. > > Need not? Please clarify what the purpose is here. It seems like > it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness? I suggest this wording: =E2=80=A6 There is no security benefit to using a ukm value that is longer than the key-encryption key that will be produced by the KDF. =20 Hmm... I believe that this statement is true, but it also seems to be incomplete. I may be reasoning about this incorrectly, but it seems to me that the minimal security requirement is that the UKM be unique, but that can be achieved with a value much smaller than the KEK. For instance, it seems like if you have a 256-bit KEK, then you would still be OK with a randomly-generated 128-bit UKM. And if we're concerned about random collisions, then the usefulness bound is actually min(|KEK|, |hash compression function = size|). =20 Yes. The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. =20 Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? =20 [JLS] I would disagree that the value has to be random, a counter will = work as well. (An encrypted counter is better.) I not be happy with a = fixed size requirement on this easier. There is no reason to make such = a requirement that I can think of. A 64-bit counter is just as = rational. It might make more sense to change this statement into = something along the lines of=20 =20 * Any pair of static keys MUST NOT be used more times than the size of = the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on the number of times the key pair can be used. * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. =20 Section 2 already says that the ephemeral key MUST be used for only one = message. Thus, a UKM is not really needed. However, the CMS requires = support for a UKM if the sender include it. For this reason, the = document says how to handle it in the KDF if it is present. =20 You are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. =20 The text already says that there is no security reason for a UKM value = that is longer than the KEK. I think that EKR is asking for guidance on = the minimum size too. =20 [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size = would be one bit. Although this is not legal from an ASN.1 standpoint = =E2=80=93 so the minimum would be one byte.=20 =20 A single byte with all bits zero and two bytes with all bits zero are = different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 =20 =20 Russ =20 ------=_NextPart_000_0169_01D2C8C6.B1CE41D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Russ Housley = [mailto:housley@vigilsec.com]
Sent: Tuesday, May 9, 2017 = 12:36 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Eric Rescorla = <ekr@rtfm.com>; curdle <curdle@ietf.org>
Subject: = Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

 

On May 9, 2017, at 1:47 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

See inline.

 

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Tuesday, May 9, 2017 9:04 = AM
To: Eric = Rescorla <ekr@rtfm.com>
Cc: curdle <curdle@ietf.org>
Subject:=  Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

I dropped the parts that have been = resolved.




> TECHNICAL
> S = 2.
>    X25519 is described in Section 6.1 of [CURVES], = and X448 is described
>    in Section 6.2 of = [CURVES].  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=E2=80=99s private key.
>    As described in = Section 7 of [CURVES], implementations SHOULD detect
>  =   this situation by checking for the all-zero = output.
>
> Why are you not requiring this check? SSH and = TLS both do.

RFC 7748 [CURVES] says:

   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.

We upgraded the MAY to a SHOULD.  We are being told = that some implementations will not perform this check, so it seemed = wrong to go all the way to = MUST.

 

I'd like to push on this some, because I'm having = trouble seeing why different IETF protocols have different needs. When = you say "you are being told" is that an S/MIME specific point = or merely the the text = above?

 

The text above, which I gather is about some existing = implementations, probably libraries.  I do not know what protocols = use those implementations, but if they are libraries they will get used = with many different protocols.

 

[JLS] As I have stated = in the past =E2=80=93 I am with EKR on = this.

 

Previously, only Jim had posted in support for this = check.  I will change the SHOULD to a = MUST.





>    The ECC-CMS-SharedInfo = entityUInfo field optionally contains
>    additional = keying material supplied by the sending agent.  Note = that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that includes the = ukm field.  If the ukm field is present,
>    the = ukm is placed in the entityUInfo field.  The ukm value need = not
>    be longer than the key-encryption key that will = be produced by the
>    KDF.
>
> Need not? = Please clarify what the purpose is here. It seems like
> it's to = generate a unique KEK. In that case, the security bounds
> are = what, uniqueness?

I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that will be = produced by
   the = KDF.

 

Hmm... I believe that this statement is true, but it = also seems to be

incomplete. I may be reasoning about this incorrectly, = but it seems

to = me that the minimal security requirement is that the UKM = be

unique, but = that can be achieved with a value much smaller = than

the KEK. = For instance, it seems like if you have a 256-bit = KEK,

then you = would still be OK with a randomly-generated = 128-bit

UKM. = And if we're concerned about random collisions, then = the

usefulness = bound is actually min(|KEK|, |hash compression function = size|).

 

Yes. The umm value needs to be different for each = invocation of the KDF, otherwise it does not provide the assurance that = different keying material will be produced.  Of course, an = implementation will generate the umm value using random number = generator, not track the values that are used.  Several years ago, = there was a discussion about the size of the ukm needed.  Some = people were suggesting crazy large values, and the point was made that = anything beyond the SIZEOF(KEK) did not improve = security.

 

Are you asking for a sentence saying that the ukm, if = present, MUST be at least 128 = bits?

 

[JLS] I would disagree = that the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of 

 

* Any pair of static = keys MUST NOT be used more times than the size of the key.  I.e. if = 128-bit KEKs may be used, then there is a 2^128 limit on the number of = times the key pair can be used.

* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any = event.

 

Section 2 already says that the ephemeral key MUST be = used for only one message.  Thus, a UKM is not really needed. =  However, the CMS requires support for a UKM if the sender include = it.  For this reason, the document says how to handle it in the KDF = if it is present.

 

You are correct that a counter, encrypted counter, or = random value will work, even if the originator uses the same ephemeral = key for many messages.  The text does not limit the choices in any = way.

 

The text already says that there is no security reason = for a UKM value that is longer than the KEK.  I think that EKR is = asking for guidance on the minimum size too.

 

[JLS] It=E2=80=99s kind of a stupid thing to do, = but the minimum size would be one bit.=C2=A0 Although this is not legal = from an ASN.1 standpoint =E2=80=93 so the minimum would be one byte. =

 

A single byte with all = bits zero and two bytes with all bits zero are different ukm values = because of the way that they are used in the ECC-CMS-SharedInfo = structure.=C2=A0 Note that this would not be the case if the ukm value = was only used as a salt value to HKDF.=C2=A0 I do not see any reason to = specify a minimum length of this value.=C2=A0 The only thing that is = required is uniqueness, EKR is correct about saying this. =

 

 

Russ

 

------=_NextPart_000_0169_01D2C8C6.B1CE41D0-- From nobody Tue May 9 13:25: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 9868012EB18 for ; Tue, 9 May 2017 13:25:47 -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 HAjG_9_e-L5y for ; Tue, 9 May 2017 13:25:46 -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 DD5CF127871 for ; Tue, 9 May 2017 13:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 524DD30050D for ; Tue, 9 May 2017 16:25:45 -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 7-0cVtRBc10K for ; Tue, 9 May 2017 16:25: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 427063004D8; Tue, 9 May 2017 16:25:42 -0400 (EDT) From: Russ Housley Message-Id: <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2223C508-17EC-4536-B737-3364BD5A14BE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 16:25:45 -0400 In-Reply-To: <016801d2c901$5e299760$1a7cc620$@augustcellars.com> Cc: curdle To: Jim Schaad , Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 20:25:47 -0000 --Apple-Mail=_2223C508-17EC-4536-B737-3364BD5A14BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>> > additional keying material supplied by the sending agent. = Note that >>>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>>> > the ukm is placed in the entityUInfo field. The ukm value = need not >>>> > be longer than the key-encryption key that will be produced by = the >>>> > KDF. >>>> > >>>> > Need not? Please clarify what the purpose is here. It seems like >>>> > it's to generate a unique KEK. In that case, the security bounds >>>> > are what, uniqueness? >>>>=20 >>>> I suggest this wording: >>>>=20 >>>> =E2=80=A6 There is no security benefit to using a ukm value that = is >>>> longer than the key-encryption key that will be produced by >>>> the KDF. >>> =20 >>> Hmm... I believe that this statement is true, but it also seems to = be >>> incomplete. I may be reasoning about this incorrectly, but it seems >>> to me that the minimal security requirement is that the UKM be >>> unique, but that can be achieved with a value much smaller than >>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>> then you would still be OK with a randomly-generated 128-bit >>> UKM. And if we're concerned about random collisions, then the >>> usefulness bound is actually min(|KEK|, |hash compression function = size|). >> =20 >> Yes. The umm value needs to be different for each invocation of the = KDF, otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. >> =20 >> Are you asking for a sentence saying that the ukm, if present, MUST = be at least 128 bits? >> =20 >> [JLS] I would disagree that the value has to be random, a counter = will work as well. (An encrypted counter is better.) I not be happy = with a fixed size requirement on this easier. There is no reason to = make such a requirement that I can think of. A 64-bit counter is just = as rational. It might make more sense to change this statement into = something along the lines of=20 >> =20 >> * Any pair of static keys MUST NOT be used more times than the size = of the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 = limit on the number of times the key pair can be used. >> * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. > =20 > Section 2 already says that the ephemeral key MUST be used for only = one message. Thus, a UKM is not really needed. However, the CMS = requires support for a UKM if the sender include it. For this reason, = the document says how to handle it in the KDF if it is present. > =20 > You are correct that a counter, encrypted counter, or random value = will work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. > =20 > The text already says that there is no security reason for a UKM value = that is longer than the KEK. I think that EKR is asking for guidance on = the minimum size too. > =20 > [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size = would be one bit. Although this is not legal from an ASN.1 standpoint = =E2=80=93 so the minimum would be one byte.=20 > =20 > A single byte with all bits zero and two bytes with all bits zero are = different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 I suggest: The ECC-CMS-SharedInfo entityUInfo field optionally contains additional keying material supplied by the sending agent. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm is placed in the entityUInfo field. When present, the ukm ensures that a different key-encryption key is generated, even when the originator ephemeral private key is improperly used more than once. Therefore, if the ukm field is present, it MUST be selected in a manner that ensures a unique KDF output; however, there is no security benefit to using a ukm value that is longer than the key- encryption key that will be produced by the KDF. Russ --Apple-Mail=_2223C508-17EC-4536-B737-3364BD5A14BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
>    The = ECC-CMS-SharedInfo entityUInfo field optionally contains
>    additional keying material supplied by the = sending agent.  Note that
>    [CMS] = requires implementations to accept a KeyAgreeRecipientInfo
>    SEQUENCE that includes the ukm field.  = If the ukm field is present,
>    the ukm is = placed in the entityUInfo field.  The ukm value need not
>    be longer than the key-encryption key that = will be produced by the
>    KDF.
>
> Need not? Please clarify what the = purpose is here. It seems like
> it's to generate a = unique KEK. In that case, the security bounds
> are = what, uniqueness?

I suggest this = wording:

   =E2=80=A6 There is no = security benefit to using a ukm value that is
  =  longer than the key-encryption key that will be produced by
   the KDF.
 
Hmm... I believe that this statement is = true, but it also seems to be
incomplete.= I may be reasoning about this incorrectly, but it seems
to me that the minimal security = requirement is that the UKM be
unique, = but that can be achieved with a value much smaller than
the KEK. For instance, it seems like if = you have a 256-bit KEK,
then you = would still be OK with a randomly-generated 128-bit
UKM. And if we're concerned about = random collisions, then the
usefulness = bound is actually min(|KEK|, |hash compression function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are you asking for a sentence saying = that the ukm, if present, MUST be at least 128 bits?
 
[JLS] I would disagree that the value has to be = random, a counter will work as well.  (An encrypted counter is = better.)  I not be happy with a fixed size requirement on this = easier.  There is no reason to make such a requirement that I can = think of.  A 64-bit counter is just as rational.  It might = make more sense to change this statement into something along the lines = of 
 
* Any pair of static keys MUST NOT be used = more times than the size of the key.  I.e. if 128-bit KEKs may be = used, then there is a 2^128 limit on the number of times the key pair = can be used.
* The size of the KEK is normally not longer than the = length of the resulting KEK as that is the limit of unique values that = can be generated in any event.
 
Section 2 already says that the ephemeral key MUST be used = for only one message.  Thus, a UKM is not really needed. =  However, the CMS requires support for a UKM if the sender include = it.  For this reason, the document says how to handle it in the KDF = if it is present.
 
You are correct that a counter, encrypted counter, or random = value will work, even if the originator uses the same ephemeral key for = many messages.  The text does not limit the choices in any way.
 
The text already says that there is no = security reason for a UKM value that is longer than the KEK.  I = think that EKR is asking for guidance on the minimum size too.
 
[JLS] It=E2=80=99s kind of = a stupid thing to do, but the minimum size would be one bit.  = Although this is not legal from an ASN.1 standpoint =E2=80=93 so the = minimum would be one byte. 
 
A single = byte with all bits zero and two bytes with all bits zero are different = ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure.  Note that this would not be the case = if the ukm value was only used as a salt value to HKDF.  I do not = see any reason to specify a minimum length of this value.  The only = thing that is required is uniqueness, EKR is correct about saying = this. 

I suggest:

   The ECC-CMS-SharedInfo = entityUInfo field optionally contains
   additional = keying material supplied by the sending agent.  Note = that
   [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
   SEQUENCE that includes the = ukm field.  If the ukm field is present,
   the = ukm is placed in the entityUInfo field.  When present, the = ukm
   ensures that a different key-encryption key = is generated, even when
   the originator ephemeral = private key is improperly used more than
   once. =  Therefore, if the ukm field is present, it MUST be selected = in
   a manner that ensures a unique KDF output; = however, there is no
   security benefit to using a = ukm value that is longer than the key-
   encryption = key that will be produced by the KDF.

Russ

= --Apple-Mail=_2223C508-17EC-4536-B737-3364BD5A14BE-- From nobody Tue May 9 14:17: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 0B60A1292D3 for ; Tue, 9 May 2017 14:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z42bcnix-meS for ; Tue, 9 May 2017 14:17:39 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 BEDB9127F0E for ; Tue, 9 May 2017 14:17:38 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 8so3564326ybw.1 for ; Tue, 09 May 2017 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BTDVhuA+4wvcZOnwqkCXHQZSx/Sift3/TiXKNrRU0Sc=; b=BDjzZbrZfHfReJA1S/KdYxI5Y9+i2xJZzMGmiasPHDWLgRvOLb4uxn7Kp8WLp04efb EGQpI8SPI4uxsd3lc8yCwjymxpqC0TNTTFwkKLPqJDFbCWPi52Jp9CyhWk6zf8SXcVph Zl9QkqC5JkVLAKjHGSKgdlz6H7nGPfCGV6Iq8F6IHr/agXND0TnE0wD5HvVHulya6REd q/BXPOJJNJ5cbiLggyHXaPD24CorEqE+e3ertuov8OlHWoXF3zoRaeZOI8jZKbnUNfi4 OWUjNf3Z+DKOXfPdciqEivgwiZXeXms7U7EKuXhBkiseHhQdIyH6hj5iT/nDUVykLhWS 9DNg== 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=BTDVhuA+4wvcZOnwqkCXHQZSx/Sift3/TiXKNrRU0Sc=; b=qFkQtF7smWhXga/xenisTCxOhTGmznguV0dMiB2xk+eRaOPp7RNvIOsuCfpLI5l57D k/CbfaS3VKs8cuP250WVqCNoBY8gx0q6V3aC5sDe2nJWrbIHOysJXJnR574lSI2sYuFk /qr60piNxCcD50A9vFSDYl2C/Om4QZ2h4AQzMAJeIzOk34Zh/zox/mfM/XZndl6jFVpx S82vbx20mpd7CFjmrg8XHr+BEzxDZxP7N4kjbvANRZl51z9K3Yd7MLuBuFPTwC/yswWp bRyDtiBSQNp3eYajO07MTHmc7F/5hBEYJiE5nF6LN8dSEtZFal4zRNUMDn9TDxCI5eyI rbmQ== X-Gm-Message-State: AODbwcB9nosYlEveVGtSupe7+UlHHE+Kvc2iO/Xbiyx5fzhQRRJHv7iX 0OzgrNpYXlyf7V/7egm/zKUpjwo98919 X-Received: by 10.37.218.145 with SMTP id n139mr1994261ybf.117.1494364658099; Tue, 09 May 2017 14:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 9 May 2017 14:16:57 -0700 (PDT) In-Reply-To: <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> From: Eric Rescorla Date: Tue, 9 May 2017 14:16:57 -0700 Message-ID: To: Russ Housley Cc: Jim Schaad , curdle Content-Type: multipart/alternative; boundary=94eb2c07e8209c9770054f1de260 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 21:17:41 -0000 --94eb2c07e8209c9770054f1de260 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 9, 2017 at 1:25 PM, Russ Housley wrote: > > The ECC-CMS-SharedInfo entityUInfo field optionally contains > > additional keying material supplied by the sending agent. Note that > > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > > SEQUENCE that includes the ukm field. If the ukm field is present, > > the ukm is placed in the entityUInfo field. The ukm value need not > > be longer than the key-encryption key that will be produced by the > > KDF. > > > > Need not? Please clarify what the purpose is here. It seems like > > it's to generate a unique KEK. In that case, the security bounds > > are what, uniqueness? > > I suggest this wording: > > =E2=80=A6 There is no security benefit to using a ukm value that is > longer than the key-encryption key that will be produced by > the KDF. > > > Hmm... I believe that this statement is true, but it also seems to be > incomplete. I may be reasoning about this incorrectly, but it seems > to me that the minimal security requirement is that the UKM be > unique, but that can be achieved with a value much smaller than > the KEK. For instance, it seems like if you have a 256-bit KEK, > then you would still be OK with a randomly-generated 128-bit > UKM. And if we're concerned about random collisions, then the > usefulness bound is actually min(|KEK|, |hash compression function size|)= . > > > Yes. The umm value needs to be different for each invocation of the KDF, > otherwise it does not provide the assurance that different keying materia= l > will be produced. Of course, an implementation will generate the umm val= ue > using random number generator, not track the values that are used. Sever= al > years ago, there was a discussion about the size of the ukm needed. Some > people were suggesting crazy large values, and the point was made that > anything beyond the SIZEOF(KEK) did not improve security. > > Are you asking for a sentence saying that the ukm, if present, MUST be at > least 128 bits? > > [JLS] I would disagree that the value has to be random, a counter will > work as well. (An encrypted counter is better.) I not be happy with a > fixed size requirement on this easier. There is no reason to make such a > requirement that I can think of. A 64-bit counter is just as rational. = It > might make more sense to change this statement into something along the > lines of > > * Any pair of static keys MUST NOT be used more times than the size of th= e > key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit on th= e > number of times the key pair can be used. > * The size of the KEK is normally not longer than the length of the > resulting KEK as that is the limit of unique values that can be generated > in any event. > > > Section 2 already says that the ephemeral key MUST be used for only one > message. Thus, a UKM is not really needed. However, the CMS requires > support for a UKM if the sender include it. For this reason, the documen= t > says how to handle it in the KDF if it is present. > > You are correct that a counter, encrypted counter, or random value will > work, even if the originator uses the same ephemeral key for many > messages. The text does not limit the choices in any way. > > The text already says that there is no security reason for a UKM value > that is longer than the KEK. I think that EKR is asking for guidance on > the minimum size too. > > [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size wou= ld be one > bit. Although this is not legal from an ASN.1 standpoint =E2=80=93 so th= e minimum > would be one byte. > > A single byte with all bits zero and two bytes with all bits zero are > different ukm values because of the way that they are used in the > ECC-CMS-SharedInfo structure. Note that this would not be the case if th= e > ukm value was only used as a salt value to HKDF. I do not see any reason > to specify a minimum length of this value. The only thing that is requir= ed > is uniqueness, EKR is correct about saying this. > > > I suggest: > > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. When present, the ukm > ensures that a different key-encryption key is generated, even when > the originator ephemeral private key is improperly used more than > once. Therefore, if the ukm field is present, it MUST be selected in > a manner that ensures a unique KDF output; > Is this actually possible? The KDF is basically a PRF, so there is some chance that 0*128 and 1*128 produce the same output. -Ekr however, there is no > security benefit to using a ukm value that is longer than the key- > encryption key that will be produced by the KDF. > > Russ > > --94eb2c07e8209c9770054f1de260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I suggest:

=C2=A0 =C2=A0The ECC-CMS-SharedInfo entityUInfo fi= eld optionally contains
=C2=A0 =C2=A0additional keying material s= upplied by the sending agent.=C2=A0 Note that
=C2=A0 =C2=A0[CMS] = requires implementations to accept a KeyAgreeRecipientInfo
=C2=A0= =C2=A0SEQUENCE that includes the ukm field.=C2=A0 If the ukm field is pres= ent,
=C2=A0 =C2=A0the ukm is placed in the entityUInfo fie= ld.=C2=A0 When present, the ukm
=C2=A0 =C2=A0ensures that a diffe= rent key-encryption key is generated, even when
=C2=A0 =C2=A0the = originator ephemeral private key is improperly used more than
=C2= =A0 =C2=A0once.=C2=A0 Therefore, if the ukm field is present, it MUST be se= lected in
=C2=A0 =C2=A0a manner that ensures a unique KDF output;=

Is this actually possibl= e? The KDF is basically a PRF, so there is some
chance that 0*128= and 1*128 produce the same output.

-Ekr

however, there is no
=C2=A0 =C2=A0= security benefit to using a ukm value that is longer than the key-
=C2=A0 =C2=A0encryption key that will be produced= by the KDF.

Russ


--94eb2c07e8209c9770054f1de260-- From nobody Tue May 9 14:26: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 4A651129B5E for ; Tue, 9 May 2017 14:26: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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS298i9bn10x for ; Tue, 9 May 2017 14:26:17 -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 9E4F912956C for ; Tue, 9 May 2017 14:26:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D2C8D0.37B1FD10" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494365166; h=from:subject:to:date:message-id; bh=8wTu8s9mwSIBXWENihdCNkhpu25wqmH2VgcNNPieZzw=; b=L8Kq3hfO8tAQRO8BHHWL6H+OIXaJSSMngW5f3sAAUJCU3MaiMto4BOQ2imSt22np2yc7/oBDsTO TXXrU+aFrZSlvbBnUptYZg3loM4agN07+C/urrylXA00DIwFbowp/ThibsPTy6IRr9+vlh1FFsziC 29RtgAnBU3PBFovxndly7DK8aLvlXtBQgvDfUdKZ0MMguEHQn/XlPeoYBgNfcLlAZcnMCaLX2qSBT IPHUhD5LNHBEMqYmRxKwnLag3H8Hk+Tj74sdViQGmvTeiBzhYOP+nboPgiZ1KWyf5OIdItjnXDZB2 iVg5xWhVnvlUN33Nh19imOj79kfENGF60RuA== 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, 9 May 2017 14:26:06 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 14:25:52 -0700 From: Jim Schaad To: 'Russ Housley' , 'Eric Rescorla' CC: 'curdle' References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> In-Reply-To: <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> Date: Tue, 9 May 2017 14:26:12 -0700 Message-ID: <017a01d2c90a$e40dc7d0$ac295770$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH9xBMcsIwTVYthAE2k4UvXwpKedQIe2gLjAVvwxw4CXdRt+QMS7ygCAmXEUp4CTue+cAHBXNlqoRuA0+A= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 21:26:20 -0000 ------=_NextPart_000_017B_01D2C8D0.37B1FD10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Tuesday, May 9, 2017 1:26 PM To: Jim Schaad ; Eric Rescorla Cc: curdle Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt =20 > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note = that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. The ukm value need not > be longer than the key-encryption key that will be produced by the > KDF. > > Need not? Please clarify what the purpose is here. It seems like > it's to generate a unique KEK. In that case, the security bounds > are what, uniqueness? I suggest this wording: =E2=80=A6 There is no security benefit to using a ukm value that is longer than the key-encryption key that will be produced by the KDF. =20 Hmm... I believe that this statement is true, but it also seems to be incomplete. I may be reasoning about this incorrectly, but it seems to me that the minimal security requirement is that the UKM be unique, but that can be achieved with a value much smaller than the KEK. For instance, it seems like if you have a 256-bit KEK, then you would still be OK with a randomly-generated 128-bit UKM. And if we're concerned about random collisions, then the usefulness bound is actually min(|KEK|, |hash compression function = size|). =20 Yes. The umm value needs to be different for each invocation of the KDF, = otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. =20 Are you asking for a sentence saying that the ukm, if present, MUST be = at least 128 bits? =20 [JLS] I would disagree that the value has to be random, a counter will = work as well. (An encrypted counter is better.) I not be happy with a = fixed size requirement on this easier. There is no reason to make such = a requirement that I can think of. A 64-bit counter is just as = rational. It might make more sense to change this statement into = something along the lines of=20 =20 * Any pair of static keys MUST NOT be used more times than the size of = the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on the number of times the key pair can be used. * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. =20 Section 2 already says that the ephemeral key MUST be used for only one = message. Thus, a UKM is not really needed. However, the CMS requires = support for a UKM if the sender include it. For this reason, the = document says how to handle it in the KDF if it is present. =20 You are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. =20 The text already says that there is no security reason for a UKM value = that is longer than the KEK. I think that EKR is asking for guidance on = the minimum size too. =20 [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size = would be one bit. Although this is not legal from an ASN.1 standpoint = =E2=80=93 so the minimum would be one byte.=20 =20 A single byte with all bits zero and two bytes with all bits zero are = different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 =20 I suggest: =20 The ECC-CMS-SharedInfo entityUInfo field optionally contains additional keying material supplied by the sending agent. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm is placed in the entityUInfo field. When present, the ukm ensures that a different key-encryption key is generated, even when the originator ephemeral private key is improperly used more than once. Therefore, if the ukm field is present, it MUST be selected in a manner that ensures a unique KDF output; however, there is no security benefit to using a ukm value that is longer than the key- encryption key that will be produced by the KDF. =20 [JLS] Looks good to me =20 Russ =20 ------=_NextPart_000_017B_01D2C8D0.37B1FD10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Russ Housley = [mailto:housley@vigilsec.com]
Sent: Tuesday, May 9, 2017 1:26 = PM
To: Jim Schaad <ietf@augustcellars.com>; Eric = Rescorla <ekr@rtfm.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] AD Review: = draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

>    The = ECC-CMS-SharedInfo entityUInfo field optionally contains
>  =   additional keying material supplied by the sending agent.  = Note that
>    [CMS] requires implementations to accept = a KeyAgreeRecipientInfo
>    SEQUENCE that includes the = ukm field.  If the ukm field is present,
>    the = ukm is placed in the entityUInfo field.  The ukm value need = not
>    be longer than the key-encryption key that will = be produced by the
>    KDF.
>
> Need not? = Please clarify what the purpose is here. It seems like
> it's to = generate a unique KEK. In that case, the security bounds
> are = what, uniqueness?

I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that will be = produced by
   the = KDF.

 

<= p class=3DMsoNormal>Hmm... I believe that this statement is true, but it = also seems to be

incomplete. I may be reasoning about this incorrectly, = but it seems

to me that the minimal security requirement is that = the UKM be

unique, but that can be achieved with a value much = smaller than

the KEK. For instance, it seems like if you have a = 256-bit KEK,

then you would still be OK with a randomly-generated = 128-bit

UKM. And if we're concerned about random collisions, = then the

usefulness bound is actually min(|KEK|, |hash = compression function = size|).

 

Yes. The umm value needs to be different for each = invocation of the KDF, otherwise it does not provide the assurance that = different keying material will be produced.  Of course, an = implementation will generate the umm value using random number = generator, not track the values that are used.  Several years ago, = there was a discussion about the size of the ukm needed.  Some = people were suggesting crazy large values, and the point was made that = anything beyond the SIZEOF(KEK) did not improve = security.

 

<= p class=3DMsoNormal>Are you asking for a sentence saying that the ukm, = if present, MUST be at least 128 = bits?

 

<= p class=3DMsoNormal>[JLS] I would disagree = that the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of 

 

* Any pair of static = keys MUST NOT be used more times than the size of the key.  I.e. if = 128-bit KEKs may be used, then there is a 2^128 limit on the number of = times the key pair can be = used.

* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any = event.

 

Section 2 already says that the ephemeral key MUST be = used for only one message.  Thus, a UKM is not really needed. =  However, the CMS requires support for a UKM if the sender include = it.  For this reason, the document says how to handle it in the KDF = if it is present.

 

You are correct that a counter, encrypted counter, or = random value will work, even if the originator uses the same ephemeral = key for many messages.  The text does not limit the choices in any = way.

 

The text already says that there is no security reason = for a UKM value that is longer than the KEK.  I think that EKR is = asking for guidance on the minimum size too.

 

[JLS] It=E2=80=99s kind = of a stupid thing to do, but the minimum size would be one bit.  = Although this is not legal from an ASN.1 standpoint =E2=80=93 so the = minimum would be one byte. 

 

A single byte with all = bits zero and two bytes with all bits zero are different ukm values = because of the way that they are used in the ECC-CMS-SharedInfo = structure.  Note that this would not be the case if the ukm value = was only used as a salt value to HKDF.  I do not see any reason to = specify a minimum length of this value.  The only thing that is = required is uniqueness, EKR is correct about saying this. 

 

I = suggest:

 

   The ECC-CMS-SharedInfo entityUInfo field = optionally contains

  =  additional keying material supplied by the sending agent. =  Note that

  =  [CMS] requires implementations to accept a = KeyAgreeRecipientInfo

   SEQUENCE that includes the ukm field. =  If the ukm field is present,

   the ukm is placed in the entityUInfo = field.  When present, the ukm

   ensures that a different key-encryption = key is generated, even when

   the originator ephemeral private key is = improperly used more than

   once.  Therefore, if the ukm field = is present, it MUST be selected in

   a manner that ensures a unique KDF = output; however, there is no

   security benefit to using a ukm value = that is longer than the key-

   encryption key that will be produced by = the KDF.

 

[JLS] Looks good to = me

 

Russ

 

------=_NextPart_000_017B_01D2C8D0.37B1FD10-- From nobody Tue May 9 15:35: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 1757C129B74 for ; Tue, 9 May 2017 15:35:50 -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 UNtZFb4DKYRB for ; Tue, 9 May 2017 15:35:48 -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 2381612EB7C for ; Tue, 9 May 2017 15:35:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2CBC03004DB for ; Tue, 9 May 2017 18:35:47 -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 c4FO5CHOIu3R for ; Tue, 9 May 2017 18:35:43 -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 B0D46300435; Tue, 9 May 2017 18:35:43 -0400 (EDT) From: Russ Housley Message-Id: <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6EE091BE-8FF1-4A20-91D2-C263BB7EB2C8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 18:35:42 -0400 In-Reply-To: Cc: Jim Schaad , curdle To: Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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, 09 May 2017 22:35:50 -0000 --Apple-Mail=_6EE091BE-8FF1-4A20-91D2-C263BB7EB2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 9, 2017, at 5:16 PM, Eric Rescorla wrote: >=20 >=20 > On Tue, May 9, 2017 at 1:25 PM, Russ Housley > wrote: >>>>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>>> > additional keying material supplied by the sending agent. = Note that >>>>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>>>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>>>> > the ukm is placed in the entityUInfo field. The ukm value = need not >>>>> > be longer than the key-encryption key that will be produced = by the >>>>> > KDF. >>>>> > >>>>> > Need not? Please clarify what the purpose is here. It seems like >>>>> > it's to generate a unique KEK. In that case, the security bounds >>>>> > are what, uniqueness? >>>>>=20 >>>>> I suggest this wording: >>>>>=20 >>>>> =E2=80=A6 There is no security benefit to using a ukm value = that is >>>>> longer than the key-encryption key that will be produced by >>>>> the KDF. >>>> =20 >>>> Hmm... I believe that this statement is true, but it also seems to = be >>>> incomplete. I may be reasoning about this incorrectly, but it seems >>>> to me that the minimal security requirement is that the UKM be >>>> unique, but that can be achieved with a value much smaller than >>>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>>> then you would still be OK with a randomly-generated 128-bit >>>> UKM. And if we're concerned about random collisions, then the >>>> usefulness bound is actually min(|KEK|, |hash compression function = size|). >>> =20 >>> Yes. The umm value needs to be different for each invocation of the = KDF, otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. >>> =20 >>> Are you asking for a sentence saying that the ukm, if present, MUST = be at least 128 bits? >>> =20 >>> [JLS] I would disagree that the value has to be random, a counter = will work as well. (An encrypted counter is better.) I not be happy = with a fixed size requirement on this easier. There is no reason to = make such a requirement that I can think of. A 64-bit counter is just = as rational. It might make more sense to change this statement into = something along the lines of=20 >>> =20 >>> * Any pair of static keys MUST NOT be used more times than the size = of the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 = limit on the number of times the key pair can be used. >>> * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. >> =20 >> Section 2 already says that the ephemeral key MUST be used for only = one message. Thus, a UKM is not really needed. However, the CMS = requires support for a UKM if the sender include it. For this reason, = the document says how to handle it in the KDF if it is present. >> =20 >> You are correct that a counter, encrypted counter, or random value = will work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. >> =20 >> The text already says that there is no security reason for a UKM = value that is longer than the KEK. I think that EKR is asking for = guidance on the minimum size too. >> =20 >> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size = would be one bit. Although this is not legal from an ASN.1 standpoint = =E2=80=93 so the minimum would be one byte.=20 >> =20 >> A single byte with all bits zero and two bytes with all bits zero are = different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 >=20 > I suggest: >=20 > The ECC-CMS-SharedInfo entityUInfo field optionally contains > additional keying material supplied by the sending agent. Note = that > [CMS] requires implementations to accept a KeyAgreeRecipientInfo > SEQUENCE that includes the ukm field. If the ukm field is present, > the ukm is placed in the entityUInfo field. When present, the ukm > ensures that a different key-encryption key is generated, even when > the originator ephemeral private key is improperly used more than > once. Therefore, if the ukm field is present, it MUST be selected = in > a manner that ensures a unique KDF output; >=20 > Is this actually possible? The KDF is basically a PRF, so there is = some > chance that 0*128 and 1*128 produce the same output. s/ensure/will with very high probability produce/ Russ --Apple-Mail=_6EE091BE-8FF1-4A20-91D2-C263BB7EB2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 9, 2017, at 5:16 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Tue, May 9, 2017 at 1:25 PM, Russ Housley <housley@vigilsec.com> = wrote:
>    The ECC-CMS-SharedInfo entityUInfo field = optionally contains
>    additional keying = material supplied by the sending agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that = includes the ukm field.  If the ukm field is present,
>    the ukm is placed in the entityUInfo = field.  The ukm value need not
>    be = longer than the key-encryption key that will be produced by the
>    KDF.
>
> = Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the = security bounds
> are what, uniqueness?
I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that = will be produced by
   the KDF.
 
Hmm... = I believe that this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me = that the minimal security requirement is that the UKM be
unique,= but that can be achieved with a value much smaller than
the = KEK. For instance, it seems like if you have a 256-bit KEK,
then = you would still be OK with a randomly-generated 128-bit
UKM. = And if we're concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression = function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are = you asking for a sentence saying that the ukm, if present, MUST be at = least 128 bits?
 
[JLS] I would disagree that = the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of =
 
* Any pair of static keys MUST = NOT be used more times than the size of the key.  I.e. if 128-bit = KEKs may be used, then there is a 2^128 limit on the number of times the = key pair can be used.
* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any event.
 
Section= 2 already says that the ephemeral key MUST be used for only one = message.  Thus, a UKM is not really needed.  However, the CMS = requires support for a UKM if the sender include it.  For this = reason, the document says how to handle it in the KDF if it is = present.
 
You = are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages.  The text does not limit the choices in any way.
 
The = text already says that there is no security reason for a UKM value that = is longer than the KEK.  I think that EKR is asking for guidance on = the minimum size too.
 
[JLS] It=E2=80=99= s kind of a stupid thing to do, but the minimum size would be one = bit.  Although this is not legal from an ASN.1 standpoint =E2=80=93 = so the minimum would be one byte. 
 
A single byte with all bits = zero and two bytes with all bits zero are different ukm values because = of the way that they are used in the ECC-CMS-SharedInfo structure.  = Note that this would not be the case if the ukm value was only used as a = salt value to HKDF.  I do not see any reason to specify a minimum = length of this value.  The only thing that is required is = uniqueness, EKR is correct about saying this. =

I suggest:

  =  The ECC-CMS-SharedInfo entityUInfo field optionally = contains
   additional keying material = supplied by the sending agent.  Note that
 =  [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
   SEQUENCE that = includes the ukm field.  If the ukm field is = present,
   the ukm is placed in = the entityUInfo field.  When present, the ukm
   ensures that a different key-encryption key is = generated, even when
   the originator = ephemeral private key is improperly used more than
   once.  Therefore, if the ukm field is = present, it MUST be selected in
   a = manner that ensures a unique KDF = output;

Is this actually possible? The KDF is = basically a PRF, so there is some
chance that 0*128 = and 1*128 produce the same = output.

s/ensure/will with very high probability = produce/

Russ


= --Apple-Mail=_6EE091BE-8FF1-4A20-91D2-C263BB7EB2C8-- From nobody Tue May 9 17:00:26 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D841298A1 for ; Tue, 9 May 2017 17:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgZkk_Xv1kis for ; Tue, 9 May 2017 17:00:22 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 7050D127078 for ; Tue, 9 May 2017 17:00:22 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id p143so4255835yba.2 for ; Tue, 09 May 2017 17:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OAAI4nqlKpfrEXY06lDImsIqz6V48zBkH8Zfu9Ps0vY=; b=XoguZFEd7iavdZbpIEHy7Y7dO2v84b6CJ5ZUDuwjgBbtc14Z+E3x1uXFiMUF3QwaX7 cRpJ+uMFoiCbbxtbcaj+gPcW62iP2aW/tzeS05Irp5KjCSyLCITO1BHT8S1gP5gZl0b/ CaM1T8S9NlVxa8h3ZFA5VoysVsswnm8WI1oEvTB04rEWVLG8/XDX3CrYsLq7MlewPC/m Qw51K5xtY87K+dQCQL/sIbQ1VwbCIe1sDpgdJIYnYIpBWZ2aRJq2JC4WNHNETwc5guNt oK1WogO2ZPiCsXneNSH2bexO1abEjuaPIXbmOliM4Xl1Apk0g0TkM/YvNtJN78TO1LAz rQmA== 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=OAAI4nqlKpfrEXY06lDImsIqz6V48zBkH8Zfu9Ps0vY=; b=CauV5WqSEzSX0SSxeTaup8wD42uvZAzG7V4I1pIJHIWa5DzWrTks/xVMnYoFNxRm6E VjC9W6WzWGJugdDUTAS/98e83BfOCAD26I7u4K9fmO76ERuOg8S7Gn7gGTa7yvHqTUc0 tpWmqh+SzSuc3VHH5SPu2FjRvARiepYCevF5UrZR5MVPzlGVfG3yV0oCF8m3li5JcUON yD5XmY/tsMItjk8Rwc84YWC7AcFbPoosrkpUR87mTeVTZjQ3KZ2pTYlN+1GvCRiTNCq9 IxCzyVO4U6boyguZCJNJZEParcC0L5403Vj5wftACees6n413Sp3Yut34n5RL0pYPSr+ 0GIA== X-Gm-Message-State: AODbwcDy80jmTv6aEUQqRRxnBBgVp0F7Hi1PsxMRXmD+xElJkzxXPEgc YMdNYqoLrmKfXAFt9braD60zqadaJw== X-Received: by 10.37.215.15 with SMTP id o15mr2599921ybg.119.1494374421655; Tue, 09 May 2017 17:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 9 May 2017 16:59:41 -0700 (PDT) In-Reply-To: <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> From: Eric Rescorla Date: Tue, 9 May 2017 16:59:41 -0700 Message-ID: To: Russ Housley Cc: Jim Schaad , curdle Content-Type: multipart/alternative; boundary=94eb2c09dc3690f37a054f20281f Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Wed, 10 May 2017 00:00:24 -0000 --94eb2c09dc3690f37a054f20281f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess I would focus on the uniqueness of the input, because the output's uniqueness is largely a function of: 1. Input uniqueness 2. The number of discrete inputs. So, I think I would say: "it MUST be selected in a manner that ensures it is unique with high probability" -Ekr On Tue, May 9, 2017 at 3:35 PM, Russ Housley wrote: > > On May 9, 2017, at 5:16 PM, Eric Rescorla wrote: > > > On Tue, May 9, 2017 at 1:25 PM, Russ Housley wrote= : > >> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >> > additional keying material supplied by the sending agent. Note tha= t >> > [CMS] requires implementations to accept a KeyAgreeRecipientInfo >> > SEQUENCE that includes the ukm field. If the ukm field is present, >> > the ukm is placed in the entityUInfo field. The ukm value need not >> > be longer than the key-encryption key that will be produced by the >> > KDF. >> > >> > Need not? Please clarify what the purpose is here. It seems like >> > it's to generate a unique KEK. In that case, the security bounds >> > are what, uniqueness? >> >> I suggest this wording: >> >> =E2=80=A6 There is no security benefit to using a ukm value that is >> longer than the key-encryption key that will be produced by >> the KDF. >> >> >> Hmm... I believe that this statement is true, but it also seems to be >> incomplete. I may be reasoning about this incorrectly, but it seems >> to me that the minimal security requirement is that the UKM be >> unique, but that can be achieved with a value much smaller than >> the KEK. For instance, it seems like if you have a 256-bit KEK, >> then you would still be OK with a randomly-generated 128-bit >> UKM. And if we're concerned about random collisions, then the >> usefulness bound is actually min(|KEK|, |hash compression function size|= ). >> >> >> Yes. The umm value needs to be different for each invocation of the KDF, >> otherwise it does not provide the assurance that different keying materi= al >> will be produced. Of course, an implementation will generate the umm va= lue >> using random number generator, not track the values that are used. Seve= ral >> years ago, there was a discussion about the size of the ukm needed. Som= e >> people were suggesting crazy large values, and the point was made that >> anything beyond the SIZEOF(KEK) did not improve security. >> >> Are you asking for a sentence saying that the ukm, if present, MUST be a= t >> least 128 bits? >> >> [JLS] I would disagree that the value has to be random, a counter will >> work as well. (An encrypted counter is better.) I not be happy with a >> fixed size requirement on this easier. There is no reason to make such = a >> requirement that I can think of. A 64-bit counter is just as rational. = It >> might make more sense to change this statement into something along the >> lines of >> >> * Any pair of static keys MUST NOT be used more times than the size of >> the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit = on >> the number of times the key pair can be used. >> * The size of the KEK is normally not longer than the length of the >> resulting KEK as that is the limit of unique values that can be generate= d >> in any event. >> >> >> Section 2 already says that the ephemeral key MUST be used for only one >> message. Thus, a UKM is not really needed. However, the CMS requires >> support for a UKM if the sender include it. For this reason, the docume= nt >> says how to handle it in the KDF if it is present. >> >> You are correct that a counter, encrypted counter, or random value will >> work, even if the originator uses the same ephemeral key for many >> messages. The text does not limit the choices in any way. >> >> The text already says that there is no security reason for a UKM value >> that is longer than the KEK. I think that EKR is asking for guidance on >> the minimum size too. >> >> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size wo= uld be >> one bit. Although this is not legal from an ASN.1 standpoint =E2=80=93 = so the >> minimum would be one byte. >> >> A single byte with all bits zero and two bytes with all bits zero are >> different ukm values because of the way that they are used in the >> ECC-CMS-SharedInfo structure. Note that this would not be the case if t= he >> ukm value was only used as a salt value to HKDF. I do not see any reaso= n >> to specify a minimum length of this value. The only thing that is requi= red >> is uniqueness, EKR is correct about saying this. >> >> >> I suggest: >> >> The ECC-CMS-SharedInfo entityUInfo field optionally contains >> additional keying material supplied by the sending agent. Note that >> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >> SEQUENCE that includes the ukm field. If the ukm field is present, >> the ukm is placed in the entityUInfo field. When present, the ukm >> ensures that a different key-encryption key is generated, even when >> the originator ephemeral private key is improperly used more than >> once. Therefore, if the ukm field is present, it MUST be selected in >> a manner that ensures a unique KDF output; >> > > Is this actually possible? The KDF is basically a PRF, so there is some > chance that 0*128 and 1*128 produce the same output. > > > s/ensure/will with very high probability produce/ > > Russ > > > --94eb2c09dc3690f37a054f20281f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess I would focus on the uniqueness of the input, beca= use the output's uniqueness is largely a function of:

1. Input uniqueness
2. The number of discrete inputs.

So, I think I would say:

"it MUST be selected in=C2=A0a manner that ensures it is unique with high probabi= lity"

-Ekr



On Tue, May 9, 2017 at 3:35 PM, = Russ Housley <housley@vigilsec.com> wrote:

On May 9, 2017, at 5:16 PM, Eri= c Rescorla <ekr@rtfm.c= om> wrote:


On Tue, May 9, 2017 at 1:25 PM, Russ Housley <housley@= vigilsec.com> wrote:
>=C2=A0 =C2=A0 The ECC-CMS-SharedInfo entityUInfo field opti= onally contains
>=C2=A0 =C2=A0 additional keying material supplied by= the sending agent.=C2=A0 Note that
>=C2=A0 =C2=A0 [CMS] requires imp= lementations to accept a KeyAgreeRecipientInfo
>=C2=A0 =C2=A0 SEQUENC= E that includes the ukm field.=C2=A0 If the ukm field is present,
>= =C2=A0 =C2=A0 the ukm is placed in the entityUInfo field.=C2=A0 The ukm val= ue need not
>=C2=A0 =C2=A0 be longer than the key-encryption key that= will be produced by the
>=C2=A0 =C2=A0 KDF.
>
> Need not= ? Please clarify what the purpose is here. It seems like
> it's t= o generate a unique KEK. In that case, the security bounds
> are what= , uniqueness?

I suggest this wording:

=C2=A0 =C2=A0=E2=80=A6 = There is no security benefit to using a ukm value that is
=C2=A0 =C2=A0l= onger than the key-encryption key that will be produced by
=C2=A0 =C2=A0= the KDF.
=C2=A0
Hmm... I believe that thi= s statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly,= but it seems
to me that= the minimal security requirement is that the UKM be
unique, but that can be achieved with a value = much smaller than
the KE= K. For instance, it seems like if you have a 256-bit KEK,
then you would still be OK with a randoml= y-generated 128-bit
UKM.= And if we're concerned about random collisions, then the=
usefulness bound is actually min(|KEK= |, |hash compression function size|).
=
=C2=A0
Yes. The umm value needs to be different for each in= vocation of the KDF, otherwise it does not provide the assurance that diffe= rent keying material will be produced.=C2=A0 Of course, an implementation w= ill generate the umm value using random number generator, not track the val= ues that are used.=C2=A0 Several years ago, there was a discussion about th= e size of the ukm needed.=C2=A0 Some people were suggesting crazy large val= ues, and the point was made that anything beyond the SIZEOF(KEK) did not im= prove security.
=C2=A0
Are you asking for a sent= ence saying that the ukm, if present, MUST be at least 128 bits?<= /u>
=C2=A0
[JLS] I would = disagree that the value has to be random, a counter will work as well.=C2= =A0 (An encrypted counter is better.)=C2=A0 I not be happy with a fixed siz= e requirement on this easier.=C2=A0 There is no reason to make such a requi= rement that I can think of.=C2=A0 A 64-bit counter is just as rational.=C2= =A0 It might make more sense to change this statement into something along = the lines of=C2=A0
=C2=A0
=
* Any pair of sta= tic keys MUST NOT be used more times than the size of the key.=C2=A0 I.e. i= f 128-bit KEKs may be used, then there is a 2^128 limit on the number of ti= mes the key pair can be used.
* The size of the KEK is normally no= t longer than the length of the resulting KEK as that is the limit of uniqu= e values that can be generated in any event.
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Section 2 already says that the ephemeral key MUST be used for onl= y one message.=C2=A0 Thus, a UKM is not really needed.=C2=A0 However, the C= MS requires support for a UKM if the sender include it.=C2=A0 For this reas= on, the document says how to handle it in the KDF if it is present.<= u>
=C2=A0
You are correct that a counter, encrypted counter, or random value wil= l work, even if the originator uses the same ephemeral key for many message= s.=C2=A0 The text does not limit the choices in any way.
=C2=A0
The te= xt already says that there is no security reason for a UKM value that is lo= nger than the KEK.=C2=A0 I think that EKR is asking for guidance on the min= imum size too.
=C2=A0
[JLS] It=E2=80=99s kind of a stup= id thing to do, but the minimum size would be one bit.=C2=A0 Although this = is not legal from an ASN.1 standpoint =E2=80=93 so the minimum would be one= byte.=C2=A0
=C2=A0
A single byte with all bits zero and two byt= es with all bits zero are different ukm values because of the way that they= are used in the ECC-CMS-SharedInfo structure.=C2=A0 Note that this would n= ot be the case if the ukm value was only used as a salt value to HKDF.=C2= =A0 I do not see any reason to specify a minimum length of this value.=C2= =A0 The only thing that is required is uniqueness, EKR is correct about say= ing this.=C2=A0

I suggest:

=C2= =A0 =C2=A0The ECC-CMS-SharedInfo entityUInfo field optionally contains
=C2=A0 =C2=A0additional keying material supplied by the sending agent= .=C2=A0 Note that
=C2=A0 =C2=A0[CMS] requires implementations to = accept a KeyAgreeRecipientInfo
=C2=A0 =C2=A0SEQUENCE that include= s the ukm field.=C2=A0 If the ukm field is present,
=C2=A0= =C2=A0the ukm is placed in the entityUInfo field.=C2=A0 When present, the = ukm
=C2=A0 =C2=A0ensures that a different key-encryption key is g= enerated, even when
=C2=A0 =C2=A0the originator ephemeral private= key is improperly used more than
=C2=A0 =C2=A0once.=C2=A0 Theref= ore, if the ukm field is present, it MUST be selected in
=C2=A0 = =C2=A0a manner that ensures a unique KDF output;

Is this actually possible? The KDF is basically a P= RF, so there is some
chance that 0*128 and 1*128 produce the same= output.

s/ensure/will with very high probability produce/

Russ

=

--94eb2c09dc3690f37a054f20281f-- From nobody Tue May 9 18:27: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 20F751293F3 for ; Tue, 9 May 2017 18:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3_Fnuts54fB for ; Tue, 9 May 2017 18:27:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0127.outbound.protection.outlook.com [104.47.34.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FA6127A90 for ; Tue, 9 May 2017 18:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I0NZFmVkkAdmKvyNwmMkXndxb6ODUjAluAXAN6vjHnY=; b=Nqy1a6b2PUN0WyfdWwcfZoKsZX66i4ZofQOCbU7QI6Pxec/WGIQTmeI91xm+/xkzJT8cK//BvKASWqm8HeMdZoPjxfLAvq6T6zkAO/ElRQGogsV3q2v60qNhLEyzJmB1JdI+q2YY3NyTRyrCbBXWnu3pXBt6Rj0dt7VpX+5vfKU= Received: from BY1PR0501CA0007.namprd05.prod.outlook.com (10.162.139.17) by MWHPR05MB2910.namprd05.prod.outlook.com (10.168.245.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 01:27:41 +0000 Received: from CO1NAM05FT064.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::203) by BY1PR0501CA0007.outlook.office365.com (2a01:111:e400:4821::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Wed, 10 May 2017 01:27:41 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT064.mail.protection.outlook.com (10.152.96.182) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Wed, 10 May 2017 01:27: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, 9 May 2017 18:27:17 -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 v4A1RHnI027757; Tue, 9 May 2017 18:27:17 -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 9C49311446; Tue, 9 May 2017 18:27:16 -0700 (PDT) To: Daniel Migault CC: Eric Rescorla , Benjamin Kaduk , Jim Schaad , Martin Thomson , curdle In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> Comments: In-reply-to: Daniel Migault message dated "Tue, 09 May 2017 18:35:02 -0000." From: "Mark D. Baushke" Date: Tue, 9 May 2017 18:27:16 -0700 Message-ID: <13876.1494379636@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39850400002)(39450400003)(39840400002)(2980300002)(199003)(189002)(9170700003)(8936002)(81166006)(8676002)(7846003)(6392003)(77096006)(5003940100001)(6306002)(189998001)(55016002)(478600001)(54906002)(106466001)(2810700001)(356003)(4326008)(2906002)(76176999)(50986999)(54356999)(39060400002)(105596002)(230783001)(110136004)(38730400002)(53376002)(305945005)(86362001)(2950100002)(48376002)(47776003)(6916009)(5660300001)(117636001)(7126002)(53416004)(76506005)(7696004)(50466002)(6246003)(6266002)(966004)(53936002)(93886004)(229853002)(42262002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2910; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT064; 1:diycHFV2IN+1WzvxNr7bIrAwjITVhrXQJb7EGxtgtMeTliH3dWE45Z2TMvudmKFuHI1qnV9SsmPd9wzI039nEub9vdeqRTe/zcQwks7+8bX6aK2upqlsugpwExHvWZkDwzcJpH9qKCASGWShf7KopgdmXCwHljtO/KY/CvMKk7aERun5+wDsCuz1mOpstAnHj0/4RMUz8EeNHWRjf2O2KNmPxt++Jx//D2UxCD4JKe2+USWGgGmFlTyUMExUhZ0O4KoE9BggkgGa3adyLVGviXbzng3hKF/UEz9bUMKURWap41lsfbjdzuN7F+ssNCcJc9l/vUbkeUsw4dIk6HTeLI8VlNhSQxgN9iJAXIziQKOWwUwhHqAkprES08XSF39PFn6954yQtoR22L4REAEau6cASKKdWWbt5I6qLGE7IfK3+Prcxz0tzDZpbIDOlM11gSm+95ChpYAsrI9Tr+rn3DuUvFiZ575tcy2fUZTMFMx5GS5h66ty0oSj2XOkbXXrXZ/+QkIv2HVEjeSik/mS+nqiBbYSO3Ov7sifgyIaXDo7So01TsGET4+zxgf8F6VprjjdV4voipoDeJzPrtoM+xuFaRKdS72vYJXZHQmjPSKC9+gZRb4cgmeokNaClGiv X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3ee59a01-da94-4220-22ac-08d49743c039 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR05MB2910; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 3:8RO2n24aEinrzWCL2DyX5MfeOWYn4GUPeWlMoPQobppNWb6VzXOi9T3wTtThoQvPl4If5rg0DXiIG+HQXWg/bAAofFFNsqzXyUJjd4+0Vdp/b2zMhvSYFYDaAnq3aeNUJxfFVSrUMLYJNus0wqbsEL6pThcojrSuXF3LSosBE8C29YyVnhJXNozpwgAVFP/KUiLWiJLx+KLWOARxPCYpS/0tD8aGfb9JiL46meTQRiHD+/e75lZSXMIdLiciu2yX6xqUK9cKlm1WCsrOft921PN/Z7AOu4FTQR6KjlwnvtmF1F2xFHWozw9Tb2z2UptLKHYeyHEX3Eel/m0z7EJ2RDU4HeeK95HWce5C0uOPL4TDSIyATYOQaw0yWIni0dHgBvXhqzp440cCWz3qFK8rILFAB9p26sTxDzIHaOrmgvsde/nA6tnLRu/z3tovT0pslb8dJLQ3tol73WwDoqK8KtRCwaV/pn2Mizdz1QSy9hBmn4RKR/wbzpPMbswJLG0c X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 25:meN4pFI51ud9idUAYCchTpHnS+4aVnVtXF2at+o0vjWOUmNh0Km8XLTpfQQtHmFuAJl0IKFTqP2BDBHtPJI6dE7z15Yd4ZBqGwjjeInxc1pZNEyYaCBYcgeRdAFcS9CMyeS1ARGfsMnxl6ypMZLfVEp5KcXMpwILEnDwXCSy1nqC5UREYCGQmpUX8LxfwEmTaKs8dSYhf4QlubvAfIMmQRU0Yfvty86wV/8It/0Zo1uz1FT3+VBTtoJim9ub3y0qPL4kmfarDEtUAo8YgC7oca7stP8Kxujw+UYexDBJNLebTqzh1W//qgFKJf1rMvBkymajnr6QW4u6bAkQt6Td0jYFtXORvMOjgGGFXlSW++lE3yKdg3aXMWvQ6dBTCzRROZ0l2sugdrCsn64iLfMAx6B0e0YhZFuA5a/2tPoUS9JlJhrn3ogCB2pxnuDgUAG5hIv6Xq54Mtwv6HeYcJdAC65RVjA/43dbtZdGzPSdyEQ=; 31:SZX2pVzagaHVDIZTlSwIvuN+1cTJ41cehl+wF87rBg8qUO5E6U1t76BT0Ga/BhtsQhjb2waegj2Ume8esYC/06ZrsPA0E97oSdvwKdGINAfW9ARCJAoko9Dz86IoCg8bsXmvQUII7dSSX7ANeVd8F9oSvESfXjaSQvwhyO48f76P9HX81ZuQOS7C/ziwMHxLuKkPdQwlYE98WWjORiU37o0XfLaxb7QO9bECMawM6Ld50S2U0Ee123TzQ6TtWale+GqEL7Q4B0kiHV+V0eXmSRAv1tvK2PZ3W23VXfabiU8= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 20:tyOusypd0yMnzo49zBf5vKTQRYCASSi+paHqSKbj9PvkD8j6tp2bXlzGxAUejAGa7p2a0xrvEFY021mSM7lPMNRhplSFqWz5SNm5tRYJAj3ujQm1ymf+L2azVOFeOgWZuiOT+ct3vEzhJC84r3dvYCes/1dwQ4J6U3O4jHzJo5T6bYhZAX/o8Strf50ugD6SQkGeN3cpcQXRzoCt7Lz7UTdigi2WInTaOTu/rC1/hLh/5uOq0/eW3Ioha7kE2FkeFtGvQlkj1l/WIvtfaTfI+3CsTGVV6T9PPWPiXsjlJwI5NJ8mo1KuwKVtWIuL7Lc4RxIzFBERHghRTxtyAUsHSMbPtmGQnIVFb4okdP9zQ2huzumAxHKPudZXwt9dDX0MHaxqrjgMUmGfWGqcEWq+thtPIS0wQSCHl1Dh9Z7h461cSPSEDmHEg3flCMTH7du7M6DXNm90qgY4KhPawc94329csXQf5MMsXTCZVBZZHcluvWbqmcoVwcwiOvmDHSSR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13023025)(13024025)(13018025)(8121501046)(5005006)(13015025)(13017025)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR05MB2910; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2910; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 4:RxUnpL10onxT2ho8oW61ilC5obmE5frKLeOZlCpaciZILw4FOJoQ9nxb/R32Ul9ZTwd6lGdYCvssS4r82UVsYDqeVcN8BShmot+2TQ6eyJmedWlAQtrK4fpqL2xwDcoVnkqjqcdIDRGWW6QR16c6bgwFKSHkzT7ahFSHNVAe4eBX14jZ3i2zketR+kXxtCWlzpRniZh3aGi08lI0FnelLI2d5pocoMmVRLCyfLEguQAIV9LBfTJHchYgtvZ4EQvsnAfx2Jfqyt+J8PViKJ6NL0Y7Gmnmse0/b+KuIheSjjI3FRaIYqag5+jmujrIK0BAwCud406uiWG/1MPcp3EfYMGLAfNP6GlZbGikcMgOFC/lnaZLpvgsrUfkZJVHcqJELrixKgG+4R09UO6le7DHEPTNMaJR6a1pP1aDr8B83WarWm7YSCo49fMXP0GTsvS08Sevrlx3tmHmN8xUgnUMQhNaPB/XK16bLDJt5tJ5iQaIhDAyyZGiEKo4mKdrcaTJWlS+NoxX9/iPUucuER43JsHZdB4vjlZuFexhk3R1dRfkdRfxiAg1RHKwY0MDwyKp7MFukYDueQt8Gf0UBOP0wF8ODLQhKq6B7qCGqHZe1h9AmXrzPgkILHzZxTU1hscySrTPPGTk9hdm89an6yARZr6YFTk9YB4/f3fiV400ii7F2vGDvY8vM/uJwZSmvGJhgOuXU96t19B7hTfinCiI4fRBHEMu28blABuaZolVhI7/sUnNedY90wUmAAXs3roNsmR25R1fuaCkCDgne7VUxis7idY0p0vam0Tt00F5FIrfJeSQUydPIrYCbfd8FwDrewREmF57IzvAh/SDwJ8QG6mF1TwiKpMrD+pjyaixJGdJ863JQJVZO5OLt8RH4dsJNuEpJIVVk6wJHVi8IggLvw== X-Forefront-PRVS: 03030B9493 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2910; 23:/kZg2TtbYrv6ahf8OvikNYhCSvm++UPFZW7e0il0g?= =?us-ascii?Q?Z1s1SquuyUqpM7aW6g2qJC7qgj0+Nva0EpNZp5nhITf2Hc69Rrb9OqbDOAs3?= =?us-ascii?Q?4MnbjbaI0B/58o/88iMGaYnqkXtnL4XQXS+l0gwhBmOIQRltnX8JI2GXOCM7?= =?us-ascii?Q?ByfVm3hcqJBgyULrryOWTxPdfPGw+P9Vysl3idZk0shizOzTBG2FFDNgU1PD?= =?us-ascii?Q?qLHoqbrx7n8r8WrtkjoZHm9e4EkxDKZY4TSwPCmPmzOm7TwyppZ29P3lISBX?= =?us-ascii?Q?C0IrEkE4CEXOePGS+htQIX6OlJjh9AcfgCO4zNGp1cPAfpDoUqubyWZzEJ+I?= =?us-ascii?Q?nSc3LQwKPq4ppAiXoXy7eyNpalU5l1EbZbFWb8JIdrYFFHmncn6TxcfbA5W5?= =?us-ascii?Q?lVMMJ/5X+jPbeIqVq9jucjxoqXU1VBCSNcCAGsGrIuZpTisdk+vCgWc8GhfO?= =?us-ascii?Q?h9y8ZJRwBCrppdiuaoa7br8Su8GMHKrd7CzigT2OmlXEt1oT+vyDWDBHZqtC?= =?us-ascii?Q?Eb5TuTIAdIPqtYbucZYQtUhDRXpFchjtd54mCis88uzLTp/vE9Fy5IfFzmi9?= =?us-ascii?Q?6NGBEr4ET2xpcEoDKeTa2stxnkls207MQRe5SlBYce32pv9U0xkY0MPf6vDe?= =?us-ascii?Q?O/FNzfTGhrwV8K/Gg0XLPMypC+VIeYRvCDSMXqTi/QahPNKI5ZBrFusLeWBK?= =?us-ascii?Q?951pDEP1bXf27WZ+gnoeIwclXCa6vWCJd37WXpJ3DLSqQIUCwXK3DQ/0uiVI?= =?us-ascii?Q?jfxmxo7S78uIX6Q0YYrTO6rlV/ykZ4DwgPCWnUj2hWePSc0/P+YNJXkMgYLW?= =?us-ascii?Q?rEng5RblQE0WzPBOpKSVa8LWpTySryx4f+fnt74iANT4lSIDRI+rbGgt7Tu1?= =?us-ascii?Q?spz+YembeAgOQle3Pvh2K37Xlu9AwwtYFfhbrCOU9lNAvQMUfDD8Fm0c6k/N?= =?us-ascii?Q?xM5hTajq7hhgJgSgmuEeaURH5eiZGrV7RPiKJjnwzvCprjXa0VQ7g1uTYBYp?= =?us-ascii?Q?lCoeI1x7/XwBl2+VaXXLlJOAfaScH06DQOLqVW00LlOt6PxiOepz/zUBqewJ?= =?us-ascii?Q?Jj92CUby36acNAL1A06fhTgAmybMW089oiDMJ8fhLi9Rk4KNNWQhi7aV3wtD?= =?us-ascii?Q?LwZ++ujDKTKz6444opGUWfGz6NDkEtRwOp2qXX4wNDXHy4N4sS3YVPjFbFjR?= =?us-ascii?Q?vXNMV9AwDzql38HXmpBulmyuYyJQTShSd/1Zo9ZZrPf9usphCIicsiISjZ/c?= =?us-ascii?Q?lhLEzLaWTks499YYiVvajOUu5xjHn1PvqvPDUr4XZqxqlp0vj7KNHX+FmNHM?= =?us-ascii?Q?OfgHd3PZ+M2DXs4hwYhxF0gHx6E31SUjm5kYS3O0kBBNrKlrWpYN4l3Ymv1O?= =?us-ascii?Q?9lwcSfAcGwbe9lPUlMjvYZU2L1rHJi/8PiQn2JufOf23R8S?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 6:43dGBzvx+7qzJlsI1kOd0seQwXt+RBTPokvqaWDuvePOa6MrUIQ0R+wNrfnS6c8VV9nBhjKKlR/Y/UhTXqWvPfQMPImC0uw2sPhfo5Hh14kR3L+qWBT9vpGkcYYpfMAhSy2dWjWuh3CHA6W7HAlOs1iNuOvwGAUbR38s7LHNL0rj8T5Bhf6h8fBEjJ6TSKr/5MxLkvixOMnhAX3eLoCvapE0ik9P1xIJ5SGqxSrjfIrJKmjBihitSuB/DnyD2MJBjawsvR++3il5oQ4YlBjLzml8yZoh0EN+zONcz8CqVYwEPDU6Z4vednpntZoeA7jHPJox2TME2/pHAgGcX3/BJX9Br+jBnI2nh+/AKHgsHey+bUbLxpLjPQu1So+rxkYc+3smMLZ9/qb5K1TN4zr60e6SnvxP5i2lLvMq6HA6+v7EvTYKQtdrvrA0Hq8TxyTIlRS7NZBd6VUw0Nz3/UOTODWChFQFtSJAerAM591KE6ZGK4R92Y61NPMUA4K3Lgx8ijV7Fwcb+VGDxVo7rpULKq4YFsdP/BITB9VcAfBgWaI=; 5:Sd0YAgDvZJoC0eisWlqXgaT0pzkHrMpvZ9zUmT8uZLPIIeykwglraheHT6Zzibl4yJqo3WmDd19VeDTYhBDkjjSrRbyaWGMp+7lldauVVL+iEsZEWwMKCC0ukS7qrz2gF1G4AZKvQc7M39R8I41hyA==; 24:Fd/qAXpCgyPM2YhRbvg05cH5lC59hib/zE/IMuI6V6WswGnK/aQBKRTOKQJq8EaieISXFoKFRs6Qa0/hWmVrMVuHnd2br+5+a6PatvOrIFY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2910; 7:V0+MQdk8979mqYaFH/mKCHWQ0aPiCy3Imo3L2I7jz6glRu0VcBy//VggGJC2s9kNggH06KksLLbOE+1yECk2Tg8UZD2f4bLoknI1tcn9sRPIL8LYfp9OQlNKCu04Dtw71ggQH8xdrlBp5Pf2Ia6DSLkNHCkeRkIc3deMpT39cFfQn0+pMboNiYQeKsiSG7tIdEKXEIC5ezAW6y7l+xwXzrILYMd8cq+0tupiX7G2dHv0pYLBQTEfzXnvNSXLWL07Wl37jDEPY3wgIBP5aSr1gdPVRYrbn+SBG0RUaaf7Jhs06eThULkCcdBnYLNp0L+pSsnI25dezj+/rMp0QAjXfA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2017 01:27:40.6943 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2910 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:27:44 -0000 Hi Daniel, I support EKR in this. The draft should be adopted by Curdle. I also think the draft seems reasonable to me as written. Does anyone know if IANA will be writing DTDs for these OIDs so that oid-info.com will be able to point to the appropriate RFCs? That is: http://www.oid-info.com/get/1.3.101.100 http://www.oid-info.com/get/1.3.101.110 http://www.oid-info.com/get/1.3.101.111 http://www.oid-info.com/get/1.3.101.112 http://www.oid-info.com/get/1.3.101.113 http://www.oid-info.com/get/1.3.101.114 http://www.oid-info.com/get/1.3.101.115 http://www.oid-info.com/get/1.3.101.120 would return appropriate information. So, who is going to need to start here: http://oid-info.com/cgi-bin/manage?f=1.3.101&a=create defining this URN going forwrd? -- Mark From nobody Tue May 9 18:31: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 3799212EBA9 for ; Tue, 9 May 2017 18:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 85YRAFXvInZE for ; Tue, 9 May 2017 18:31:53 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 103141294DB for ; Tue, 9 May 2017 18:31:52 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f102so4804348ioi.2 for ; Tue, 09 May 2017 18:31:52 -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=MfDVYsHsV9uTSXKBvNUOS32YNfOvVg6BZVZl+xubSO0=; b=ef/lmI0fMCktMkp6vp25MZfmTgjQ1G+xwuAobqvZwLADpqN8nJCe+O1uNkmCjZsSkS HlNg+sc67DgUOwopXX9uoj5EF96g0Cdg0yyH7w4Qq6Z0NhUj/GMzcOJYSNwEnxU7+52T ZSHy3y0lsC30jdp2dPnRF59Q5gKmnACYilxatIhU8RRjcpruPUdSnb/6v6TzV/8nQ9jQ uXPIs2hrwi14Y2Tt+hYrXfDQvpIr59PUR4r9gbiSXzNLQ6jDjZTbJXw4uLDSr2ZcSvyH qdUNSJUHeE/mEG2W2XtnpN3LAlUHGPHSoij67Z4RdRVnkJbAJVWoGRXj4h+scSF2NtJh FHFw== 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=MfDVYsHsV9uTSXKBvNUOS32YNfOvVg6BZVZl+xubSO0=; b=DekhsMPhQ2f/Um/JPTWeOpBiE7F1ByhlkVP2z7tTlPaRNvOh41Q3nIrcl9kDZ1sNMR b7JbherlPXwida2b8EHh8XpFXFUOVKxaVwQ3kDLTPXAfSmW+8CxvVqSU4oMQx0NKPb3B jn5GDM0cHeph2Y5Wuhy3NdSVK/TrVFX5kQxpaHsWVI9e8995wPOEYgOCE2zV7tRu17IK E17atQbq3PlRwEyRESGalW7UD/uWCj/aOXXQPze56rBgmMGHr71tg56T1BBQJqbrefk3 jW85GsF+ZfRybgsM2TnqvGliosy7FDZJ+gCIIEFoKUi7j2bxzd+hpywPA/nT8LXBhnk7 q9Rg== X-Gm-Message-State: AODbwcDiBsZdGq7FQhD66qoGM1UTMYuLUBVhi/UNNChAmE3vCQTJbWEN dHH0wzAV02smnF8u5dcF9yO2dk6cCXI5 X-Received: by 10.107.12.28 with SMTP id w28mr1259471ioi.209.1494379912059; Tue, 09 May 2017 18:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Tue, 9 May 2017 18:31:51 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Tue, 9 May 2017 15:31:51 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 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: Wed, 10 May 2017 01:31:55 -0000 Here are some more test vectors for INVALID edge cases of Ed25519 and X25519 PKCS#8 v2 keys that I would like to have included in the RFC. Ed25519 INVALID. The first byte of the public key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM -----END PRIVATE KEY----- Ed25519 INVALID. The last byte of the public key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk -----END PRIVATE KEY----- Ed25519 INVALID. The first byte of the private key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw MhAGNFfNTf3Q6YpTeWJlgx1GrGpaaF8qVMlpejiyyADWC6 -----END PRIVATE KEY----- Ed25519 INVALID. The last byte of the private key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw MhABrrjj7lulr9kRE0ZtGfTqd/oP7/vYxa3LSZkn8SU193 -----END PRIVATE KEY----- Ed25519 INVALID. The version is v1 but the publicKey field is included. -----BEGIN PRIVATE KEY----- MFMCAQAwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw== -----END PRIVATE KEY----- Ed25519 INVALID. The version is v2 but the publicKey field is missing. -----BEGIN PRIVATE KEY----- MC4CAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA -----END PRIVATE KEY----- Ed25519 INVALID. The publicKey field is indicated with [0] instead of [1]; i.e. the attributes are invalid and publicKey is missing. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw== -----END PRIVATE KEY----- X25519 INVALID. The private key's last byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw MhAOWJcLaHaY9hIDkvGBm2JKcXLJyuxCsL83hbQMYGzChg -----END PRIVATE KEY----- X25519 INVALID. The private key's first byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw MhANTsroYyWV7Klhb92EAP8ungtlqQxS58Bm7mPT7RjB4H -----END PRIVATE KEY----- X25519 INVALID. The public key's first byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS IDIAA7eraRAqyFgDnLBqnjanLu6rRLHvnWHAaB5BRwLf8P -----END PRIVATE KEY----- X25519 INVALID. The public key's last byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS IDIACZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCY -----END PRIVATE KEY----- X25519 INVALID. The version is v1 but it has a publicKey field. -----BEGIN PRIVATE KEY----- MFMCAQAwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA== -----END PRIVATE KEY----- X25519 INVALID. The publicKey field is indicated with [0] instead of [1]; i.e. the attributes are invalid and publicKey is missing. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA== -----END PRIVATE KEY----- X25519 INVALID. The version is v2 but there is no publicKey field. -----BEGIN PRIVATE KEY----- MC4CAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA -----END PRIVATE KEY----- Cheers, Brian On Sun, May 7, 2017 at 7:39 PM, Brian Smith wrote: > On Sun, May 7, 2017 at 1:46 PM, Brian Smith wrote: >> Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the public >> key included, that I'd like to have included in the RFC as test >> vectors. The first four examples are valid (I hope!) and 5th example >> is invalid. > > Here are 4 pairs of example X25519 PKCS#8 v2 keys. The first key in > each pair has its public key's high bit clear. The second key in each > pair is the same except it has its public key's high bit set. > > The private key ends with a zero byte. The public key's high bit > is zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA== > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswo4A== > -----END PRIVATE KEY----- > > The private key starts with a zero byte. The public key's high bit > is zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS > MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0YweBw== > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS > MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0Ywehw== > -----END PRIVATE KEY----- > > The public key starts with a zero byte. The public key's high bit > is zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS > MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/Dw== > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS > MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/jw== > -----END PRIVATE KEY----- > > The public key ends with a zero byte, and thus its high bit is > zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS > MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYAA== > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS > MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYgA== > -----END PRIVATE KEY----- > > Cheers, > Brian > -- > https://briansmith.org/ -- https://briansmith.org/ From nobody Wed May 10 03:26: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 393BE12946C for ; Wed, 10 May 2017 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 g3V5H7w4dgMu for ; Wed, 10 May 2017 03:26:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1D5129401 for ; Wed, 10 May 2017 03:26:54 -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 8306437E65 for ; Wed, 10 May 2017 10:26:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8306437E65 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=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8306437E65 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 50D7117560 for ; Wed, 10 May 2017 10:26:54 +0000 (UTC) From: Hubert Kario To: curdle@ietf.org Date: Wed, 10 May 2017 12:26:47 +0200 Message-ID: <3354972.PP4v7qzrL4@pintsize.usersys.redhat.com> In-Reply-To: <149221433384.15894.2426718340325647925@ietfa.amsl.com> References: <149221433384.15894.2426718340325647925@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart298886675.fIePujK7ou"; 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.29]); Wed, 10 May 2017 10:26:54 +0000 (UTC) Archived-At: Subject: [Curdle] Typo in draft-ietf-curdle-ssh-modp-dh-sha2-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: Wed, 10 May 2017 10:26:56 -0000 --nextPart298886675.fIePujK7ou Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > The group15 through group18 names are the same as those specified in > [RFC3526] 3071-bit MODP Group 15, should be "3072-bit MODP" =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 --nextPart298886675.fIePujK7ou 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 iQIcBAABCgAGBQJZEurnAAoJEJKo0bgB0vX1zSMQAIAUy61tfXESq7VNK/uVP1LT AfgPcASUno5se97UZ3VcgsPt/agVn+2EkSDqI0p+Cv3UJOwhho/QtpUA7MwxtZWA RO0vS006PN/hrEXe0v/cfi62fyYEhrodekUNtSD6mO4utN9WRzprZ/3egoJHOks8 V5DU+cNFQJzhMmKoZy/uzQ4OGTsxV5VSilIGSjrWl35FGqrx6qjdh4Rx2I//MhUi Dfu4sIncEwAvDUQLxr6Ke1JJVlgY9S2JesDTMSprFAO7pLL5ISr0cSmNLTJJKcxX kZTt4rNSBW+u5gYk/9AP29Gcs+UltSjbpjH1tf8418N7YsS00616lirg1OyjPGak Zugo8TiibvUQ1ubzBHF0FIo3ie1DEemvlR5Psdl+MFGWzJAOpcX1fnixhtlW50Ff 3CmkUWBRGg9Rw0gPQNc+FSP+4ZByxqGr7Jh+qvjc0JyNliE1EX2cS3d/gOtu/cbT 0ma92zeAD742zaL8JAUL+G7OZOA/Xwq2GdnGPkBaN9ca6ufz4rOCSYyhwv6C3FfE 9Ha4nG2vCY2pKe/b7q0mWl5tK9Tr7eq8HRNbTJw2nBRQxyQvcWZsPzK0GwivxIof y9jHl9Vv6ZaSMNk71TB57A9/8l8p/tBcoTChwq31mpTD8jVU55Y0/4MP4G4nTENe FK4P4Kull4D/B9KwFdbF =EKg8 -----END PGP SIGNATURE----- --nextPart298886675.fIePujK7ou-- From nobody Wed May 10 05:28: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 153261201FA for ; Wed, 10 May 2017 05:28:24 -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 IcyPLZmvQ0GU for ; Wed, 10 May 2017 05:28:22 -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 4FCCE129ADA for ; Wed, 10 May 2017 05:28:17 -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=1494419285; h=from:subject:to:date:message-id; bh=A5+aRcv89JeX5ZGrajDGXcwC0zsqwiuZEbUYKANJSNg=; b=X+uFz9PlcND+OEGXlH4tJQBNGtjdCA0lJv8tfZs0HCIEQ13a6VkJXdlP2v2/kZspP0mz7xW06uP Ue6S8fgxVZfEdvo3IvBcrIu9qEORZmi7cQNKXnhLLp/npNg21n4959dTRbgHKEjnlOR/HyZuMmEBQ 8OsuqHiMXb8MNpy/ihy5QWWFSywCpcFH5jkuMCOt2f5iCkUwXU8amT5oAVdNKS0BOonXf8hM0XqP5 aRsP6PzLwisS+meVxS1hcdmrY2gy8owtmziHsmEjFyle0Eb9Q/sRpWMW2uH5+NJ/erHGWPclDeI/o NjjxwsBZ78U6oQSfD5x3MjPvGpTJvAGcN40w== 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, 10 May 2017 05:28:05 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 05:27:53 -0700 From: Jim Schaad To: , 'Daniel Migault' CC: 'Eric Rescorla' , 'Benjamin Kaduk' , "'Martin Thomson'" , 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <13876.1494379636@eng-mail01.juniper.net> In-Reply-To: <13876.1494379636@eng-mail01.juniper.net> Date: Wed, 10 May 2017 05:28:13 -0700 Message-ID: <000501d2c988$e6c681f0$b45385d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAWt1TpUBWsHjHAN7FOQdAZi7CHQBRXVEwwHSbWjqAhDWZLahhpqgwA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:28:24 -0000 I do not believe that this has historically been part of the IANA mission. Jim -----Original Message----- From: mdb@juniper.net [mailto:mdb@juniper.net] Sent: Tuesday, May 9, 2017 6:27 PM To: Daniel Migault Cc: Eric Rescorla ; Benjamin Kaduk ; Jim Schaad ; Martin Thomson ; curdle Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt Hi Daniel, I support EKR in this. The draft should be adopted by Curdle. I also think the draft seems reasonable to me as written. Does anyone know if IANA will be writing DTDs for these OIDs so that oid-info.com will be able to point to the appropriate RFCs? That is: http://www.oid-info.com/get/1.3.101.100 http://www.oid-info.com/get/1.3.101.110 http://www.oid-info.com/get/1.3.101.111 http://www.oid-info.com/get/1.3.101.112 http://www.oid-info.com/get/1.3.101.113 http://www.oid-info.com/get/1.3.101.114 http://www.oid-info.com/get/1.3.101.115 http://www.oid-info.com/get/1.3.101.120 would return appropriate information. So, who is going to need to start here: http://oid-info.com/cgi-bin/manage?f=1.3.101&a=create defining this URN going forwrd? -- Mark From nobody Wed May 10 06:50: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 3D711129451 for ; Wed, 10 May 2017 06:50:15 -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 XzjdhZcKiYFs for ; Wed, 10 May 2017 06:50: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 A023112422F for ; Wed, 10 May 2017 06:50:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EBBF230050E for ; Wed, 10 May 2017 09:50:11 -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 Q3Q2R5ayQ4cC for ; Wed, 10 May 2017 09:50:08 -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 A2D2D300494; Wed, 10 May 2017 09:50:08 -0400 (EDT) From: Russ Housley Message-Id: <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2BCA22ED-DB28-4E51-AB54-119D38D3FDEB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 09:50:08 -0400 In-Reply-To: Cc: Jim Schaad , curdle To: Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Wed, 10 May 2017 13:50:15 -0000 --Apple-Mail=_2BCA22ED-DB28-4E51-AB54-119D38D3FDEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, that works for me. I=E2=80=99ll post an updated I-D later today. Russ > On May 9, 2017, at 7:59 PM, Eric Rescorla wrote: >=20 > I guess I would focus on the uniqueness of the input, because the = output's uniqueness is largely a function of: >=20 > 1. Input uniqueness > 2. The number of discrete inputs. >=20 > So, I think I would say: >=20 > "it MUST be selected in a manner that ensures it is unique with high = probability" >=20 > -Ekr >=20 >=20 >=20 > On Tue, May 9, 2017 at 3:35 PM, Russ Housley > wrote: >=20 >> On May 9, 2017, at 5:16 PM, Eric Rescorla > wrote: >>=20 >>=20 >> On Tue, May 9, 2017 at 1:25 PM, Russ Housley > wrote: >>>>>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>>>> > additional keying material supplied by the sending agent. = Note that >>>>>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>>>>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>>>>> > the ukm is placed in the entityUInfo field. The ukm value = need not >>>>>> > be longer than the key-encryption key that will be produced = by the >>>>>> > KDF. >>>>>> > >>>>>> > Need not? Please clarify what the purpose is here. It seems = like >>>>>> > it's to generate a unique KEK. In that case, the security = bounds >>>>>> > are what, uniqueness? >>>>>>=20 >>>>>> I suggest this wording: >>>>>>=20 >>>>>> =E2=80=A6 There is no security benefit to using a ukm value = that is >>>>>> longer than the key-encryption key that will be produced by >>>>>> the KDF. >>>>> =20 >>>>> Hmm... I believe that this statement is true, but it also seems to = be >>>>> incomplete. I may be reasoning about this incorrectly, but it = seems >>>>> to me that the minimal security requirement is that the UKM be >>>>> unique, but that can be achieved with a value much smaller than >>>>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>>>> then you would still be OK with a randomly-generated 128-bit >>>>> UKM. And if we're concerned about random collisions, then the >>>>> usefulness bound is actually min(|KEK|, |hash compression function = size|). >>>> =20 >>>> Yes. The umm value needs to be different for each invocation of the = KDF, otherwise it does not provide the assurance that different keying = material will be produced. Of course, an implementation will generate = the umm value using random number generator, not track the values that = are used. Several years ago, there was a discussion about the size of = the ukm needed. Some people were suggesting crazy large values, and the = point was made that anything beyond the SIZEOF(KEK) did not improve = security. >>>> =20 >>>> Are you asking for a sentence saying that the ukm, if present, MUST = be at least 128 bits? >>>> =20 >>>> [JLS] I would disagree that the value has to be random, a counter = will work as well. (An encrypted counter is better.) I not be happy = with a fixed size requirement on this easier. There is no reason to = make such a requirement that I can think of. A 64-bit counter is just = as rational. It might make more sense to change this statement into = something along the lines of=20 >>>> =20 >>>> * Any pair of static keys MUST NOT be used more times than the size = of the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 = limit on the number of times the key pair can be used. >>>> * The size of the KEK is normally not longer than the length of the = resulting KEK as that is the limit of unique values that can be = generated in any event. >>> =20 >>> Section 2 already says that the ephemeral key MUST be used for only = one message. Thus, a UKM is not really needed. However, the CMS = requires support for a UKM if the sender include it. For this reason, = the document says how to handle it in the KDF if it is present. >>> =20 >>> You are correct that a counter, encrypted counter, or random value = will work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. >>> =20 >>> The text already says that there is no security reason for a UKM = value that is longer than the KEK. I think that EKR is asking for = guidance on the minimum size too. >>> =20 >>> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum = size would be one bit. Although this is not legal from an ASN.1 = standpoint =E2=80=93 so the minimum would be one byte.=20 >>> =20 >>> A single byte with all bits zero and two bytes with all bits zero = are different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 >>=20 >> I suggest: >>=20 >> The ECC-CMS-SharedInfo entityUInfo field optionally contains >> additional keying material supplied by the sending agent. Note = that >> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >> SEQUENCE that includes the ukm field. If the ukm field is = present, >> the ukm is placed in the entityUInfo field. When present, the ukm >> ensures that a different key-encryption key is generated, even = when >> the originator ephemeral private key is improperly used more than >> once. Therefore, if the ukm field is present, it MUST be selected = in >> a manner that ensures a unique KDF output; >>=20 >> Is this actually possible? The KDF is basically a PRF, so there is = some >> chance that 0*128 and 1*128 produce the same output. >=20 > s/ensure/will with very high probability produce/ >=20 > Russ >=20 >=20 >=20 --Apple-Mail=_2BCA22ED-DB28-4E51-AB54-119D38D3FDEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, that works for me.  I=E2=80=99ll post an updated = I-D later today.

Russ


On May 9, 2017, at 7:59 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

I guess I would focus on the uniqueness of the = input, because the output's uniqueness is largely a function of:

1. Input = uniqueness
2. The number of discrete = inputs.

So, I = think I would say:

"it MUST be = selected in a = manner that ensures it is unique with high probability"

-Ekr



On Tue, May 9, 2017 at 3:35 PM, = Russ Housley <housley@vigilsec.com> wrote:

On May 9, 2017, at 5:16 PM, Eric Rescorla = <ekr@rtfm.com> wrote:


On Tue, May 9, 2017 at 1:25 PM, = Russ Housley <housley@vigilsec.com> wrote:
>    The ECC-CMS-SharedInfo entityUInfo field = optionally contains
>    additional keying = material supplied by the sending agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that = includes the ukm field.  If the ukm field is present,
>    the ukm is placed in the entityUInfo = field.  The ukm value need not
>    be = longer than the key-encryption key that will be produced by the
>    KDF.
>
> = Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the = security bounds
> are what, uniqueness?
I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that = will be produced by
   the KDF.
 
Hmm... = I believe that this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me = that the minimal security requirement is that the UKM be
unique,= but that can be achieved with a value much smaller than
the = KEK. For instance, it seems like if you have a 256-bit KEK,
then = you would still be OK with a randomly-generated 128-bit
UKM. = And if we're concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression = function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are = you asking for a sentence saying that the ukm, if present, MUST be at = least 128 bits?
 
[JLS] I would disagree that = the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of 
 
* Any pair of static keys MUST = NOT be used more times than the size of the key.  I.e. if 128-bit = KEKs may be used, then there is a 2^128 limit on the number of times the = key pair can be used.
* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any event.
 
Section= 2 already says that the ephemeral key MUST be used for only one = message.  Thus, a UKM is not really needed.  However, the CMS = requires support for a UKM if the sender include it.  For this = reason, the document says how to handle it in the KDF if it is = present.
 
You = are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages.  The text does not limit the choices in any way.
 
The = text already says that there is no security reason for a UKM value that = is longer than the KEK.  I think that EKR is asking for guidance on = the minimum size too.
 
[JLS] It=E2=80=99= s kind of a stupid thing to do, but the minimum size would be one = bit.  Although this is not legal from an ASN.1 standpoint =E2=80=93 = so the minimum would be one byte. 
 
A single byte with all bits = zero and two bytes with all bits zero are different ukm values because = of the way that they are used in the ECC-CMS-SharedInfo structure.  = Note that this would not be the case if the ukm value was only used as a = salt value to HKDF.  I do not see any reason to specify a minimum = length of this value.  The only thing that is required is = uniqueness, EKR is correct about saying this. 

I suggest:

   The ECC-CMS-SharedInfo entityUInfo field = optionally contains
   additional keying = material supplied by the sending agent.  Note that
   [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
   SEQUENCE that = includes the ukm field.  If the ukm field is = present,
   the ukm is placed in = the entityUInfo field.  When present, the ukm
   ensures that a different key-encryption key is = generated, even when
   the originator = ephemeral private key is improperly used more than
   once.  Therefore, if the ukm field is = present, it MUST be selected in
   a = manner that ensures a unique KDF = output;

Is this actually possible? The KDF is = basically a PRF, so there is some
chance that 0*128 = and 1*128 produce the same = output.

s/ensure/will with very = high probability produce/

Russ




= --Apple-Mail=_2BCA22ED-DB28-4E51-AB54-119D38D3FDEB-- From nobody Wed May 10 07:07:09 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 7410F129B56; Wed, 10 May 2017 07:07: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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442522143.22664.13277345861380346642@ietfa.amsl.com> Date: Wed, 10 May 2017 07:07:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:07:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-06.txt Pages : 16 Date : 2017-05-10 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 07: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 1AB30127077 for ; Wed, 10 May 2017 07:08:58 -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 46WPFTUtunJq for ; Wed, 10 May 2017 07:08:56 -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 D6024126CF6 for ; Wed, 10 May 2017 07:08:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 458B0300545 for ; Wed, 10 May 2017 10:08:56 -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 TxvQ-xerRhtg for ; Wed, 10 May 2017 10:08:55 -0400 (EDT) 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 17A0F300538 for ; Wed, 10 May 2017 10:08:55 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 10:08:56 -0400 References: <149442522143.22664.13277345861380346642@ietfa.amsl.com> To: curdle In-Reply-To: <149442522143.22664.13277345861380346642@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:08:58 -0000 These changes capture the discussion between Eric Rescorla, Jim Schaad, = and myself. I believe that the comments from Eric=E2=80=99s AD review = are now resolved. Russ > On May 10, 2017, at 10:07 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-Hellman Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-ecdh-new-curves-06.txt > Pages : 16 > Date : 2017-05-10 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and > curve448 in the Cryptographic Message Syntax (CMS). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 06 >=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 Wed May 10 07:21: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 CBF21129B76 for ; Wed, 10 May 2017 07:21: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 74m3qlZfNq-5 for ; Wed, 10 May 2017 07:21: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 AEBA412946C for ; Wed, 10 May 2017 07:21:27 -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=1494426082; h=from:subject:to:date:message-id; bh=Hjg/4/0aoW7UMzNzyNmECU+veIEfn2mJvSmiyFYaHkk=; b=Hh5Uz4RBMbT6p37zdrwrCdpsOKCBB0g6hXX0BTAHnidgvGKUUX3y5ixV4KkwYa1eHuK1QXbaxQm PDjdJlnab8YKZjpN9UfermOErbwQinxN6DDrAbew3SxP8ld55uswLZnEapiGuETqgOt8zQggr7uh3 70qthclq2v7GAHI6vDXJiT8eISrZAKosKxSpHrAFPHC9zbg2LRGBOtDU1eFj/WmWdLIiEOqqTDcTM CLhS3zrbLH0ZrFmuo98LGOBCBdlSFU5Zuy/HpENujGJsMXI2v/RrdfS9PnRzXicC9u56yf5bPAWsi u9Ob4q/DpZwbyymLdt/lo1OuxBykZA1lMKMg== 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, 10 May 2017 07:21:22 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 07:21:11 -0700 From: Jim Schaad To: 'Brian Smith' CC: 'curdle' References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> In-Reply-To: Date: Wed, 10 May 2017 07:21:31 -0700 Message-ID: <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQdwJ1Iy/iAhSOZKsB1zCbUwHBSJH8AuMjGPgCXdDW9gIx5lJ3otbFd+A= X-Originating-IP: [24.21.96.37] 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: Wed, 10 May 2017 14:21:30 -0000 I have not yet gotten to the point of validating the edge cases, = although the number seems to be getting to the point of a test suite = which I would prefer to handle in a different manner. I have been reading the curve drafts and looking at my implementation to = try and figure out what the rules are and what the implications are = relative to what is being asked for. Public keys - I think that it makes sense to talk about saying that = checks needs to be done on public keys. For the set of checks I can = just reference the two drafts, I do not think that I need to re-state = them in this draft. Private keys - There is a slightly interesting trade-off that may need = to be considered at this point. One can either have the keys in the = correct format, or one can require that the correct masking be applied = during the import step. The reason for requiring the latter is that it = removes some of the fixed structure of the private key. This has a = (very small) advantage as a totally random item is harder to make = guesses at. It is true however that there is other structure in the = text that is encrypted so this would be a very small advantage. When I = wrote my code, I did the import and then the masking step as the masking = needs to be done in a lot of cases when operations are done. Do people = have opinions on this? OneAsymmetricKey version numbering - I am looking at putting some = guidance text on this into the document. I will send it out once I am = happy with it. Jim -----Original Message----- From: Brian Smith [mailto:brian@briansmith.org]=20 Sent: Tuesday, May 9, 2017 6:32 PM To: Jim Schaad Cc: curdle Subject: Re: [Curdle] FW: New Version Notification for = draft-ietf-curdle-pkix-04.txt Here are some more test vectors for INVALID edge cases of Ed25519 and X25519 PKCS#8 v2 keys that I would like to have included in the RFC. Ed25519 INVALID. The first byte of the public key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM -----END PRIVATE KEY----- Ed25519 INVALID. The last byte of the public key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk -----END PRIVATE KEY----- Ed25519 INVALID. The first byte of the private key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw MhAGNFfNTf3Q6YpTeWJlgx1GrGpaaF8qVMlpejiyyADWC6 -----END PRIVATE KEY----- Ed25519 INVALID. The last byte of the private key, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VwBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw MhABrrjj7lulr9kRE0ZtGfTqd/oP7/vYxa3LSZkn8SU193 -----END PRIVATE KEY----- Ed25519 INVALID. The version is v1 but the publicKey field is included. -----BEGIN PRIVATE KEY----- MFMCAQAwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw=3D=3D -----END PRIVATE KEY----- Ed25519 INVALID. The version is v2 but the publicKey field is missing. -----BEGIN PRIVATE KEY----- MC4CAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA -----END PRIVATE KEY----- Ed25519 INVALID. The publicKey field is indicated with [0] instead of = [1]; i.e. the attributes are invalid and publicKey is missing. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw=3D=3D -----END PRIVATE KEY----- X25519 INVALID. The private key's last byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw MhAOWJcLaHaY9hIDkvGBm2JKcXLJyuxCsL83hbQMYGzChg -----END PRIVATE KEY----- X25519 INVALID. The private key's first byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw MhANTsroYyWV7Klhb92EAP8ungtlqQxS58Bm7mPT7RjB4H -----END PRIVATE KEY----- X25519 INVALID. The public key's first byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS IDIAA7eraRAqyFgDnLBqnjanLu6rRLHvnWHAaB5BRwLf8P -----END PRIVATE KEY----- X25519 INVALID. The public key's last byte, zero, is omitted. -----BEGIN PRIVATE KEY----- MFICAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS IDIACZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCY -----END PRIVATE KEY----- X25519 INVALID. The version is v1 but it has a publicKey field. -----BEGIN PRIVATE KEY----- MFMCAQAwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D -----END PRIVATE KEY----- X25519 INVALID. The publicKey field is indicated with [0] instead of = [1]; i.e. the attributes are invalid and publicKey is missing. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D -----END PRIVATE KEY----- X25519 INVALID. The version is v2 but there is no publicKey field. -----BEGIN PRIVATE KEY----- MC4CAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA -----END PRIVATE KEY----- Cheers, Brian On Sun, May 7, 2017 at 7:39 PM, Brian Smith = wrote: > On Sun, May 7, 2017 at 1:46 PM, Brian Smith = wrote: >> Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the=20 >> public key included, that I'd like to have included in the RFC as=20 >> test vectors. The first four examples are valid (I hope!) and 5th=20 >> example is invalid. > > Here are 4 pairs of example X25519 PKCS#8 v2 keys. The first key in=20 > each pair has its public key's high bit clear. The second key in each=20 > pair is the same except it has its public key's high bit set. > > The private key ends with a zero byte. The public key's high bit is=20 > zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is=20 > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswo4A=3D=3D > -----END PRIVATE KEY----- > > The private key starts with a zero byte. The public key's high bit is=20 > zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS > MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0YweBw=3D=3D > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is=20 > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS > MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0Ywehw=3D=3D > -----END PRIVATE KEY----- > > The public key starts with a zero byte. The public key's high bit is=20 > zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS > MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/Dw=3D=3D > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is=20 > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS > MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/jw=3D=3D > -----END PRIVATE KEY----- > > The public key ends with a zero byte, and thus its high bit is zero. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS > MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYAA=3D=3D > -----END PRIVATE KEY----- > > The private key is the same as the previous one. The public key is=20 > also the same except its high bit is one. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS > MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYgA=3D=3D > -----END PRIVATE KEY----- > > Cheers, > Brian > -- > https://briansmith.org/ -- https://briansmith.org/ From nobody Wed May 10 07:49: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 5F0A4129BC4 for ; Wed, 10 May 2017 07:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRNfTurA__cC for ; Wed, 10 May 2017 07:49:55 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160911294B8 for ; Wed, 10 May 2017 07:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4e2oka9PnDJa7AOFtXv+an9moW0mPRcUEgK5S4x9Mt4=; b=RumMksL/o6aV1cSdStaNz79Z3+d/zQq+BmdS5ptr41eEXcYZpi7P5KShgt5xDVXu5gbKEo8/85obhSBorHPA79fcGsXo9sMKco4fA9BUAA+o4zpHXtpeEsWlGiqsPf2v3YxqBRN0Wa/vThkq6DA/2iHtM7+KBvSUjAawtBJCqSg= Received: from BY1PR0501CA0014.namprd05.prod.outlook.com (10.162.139.24) by BN1PR05MB264.namprd05.prod.outlook.com (10.141.65.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 14:49:52 +0000 Received: from CO1NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::204) by BY1PR0501CA0014.outlook.office365.com (2a01:111:e400:4821::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Wed, 10 May 2017 14:49:51 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT038.mail.protection.outlook.com (10.152.96.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Wed, 10 May 2017 14:49:50 +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; Wed, 10 May 2017 07:49:50 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4AEnlJW003571; Wed, 10 May 2017 07:49:47 -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 617A011454; Wed, 10 May 2017 07:49:47 -0700 (PDT) To: Jim Schaad CC: Daniel Migault , Eric Rescorla , Benjamin Kaduk , Martin Thomson , curdle In-Reply-To: <000501d2c988$e6c681f0$b45385d0$@augustcellars.com> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <13876.1494379636@eng-mail01.juniper.net> <000501d2c988$e6c681f0$b45385d0$@augustcellars.com> Comments: In-reply-to: Jim Schaad message dated "Wed, 10 May 2017 05:28:13 -0700." From: "Mark D. Baushke" Date: Wed, 10 May 2017 07:49:47 -0700 Message-ID: <92705.1494427787@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(39400400002)(2980300002)(189002)(199003)(9170700003)(189998001)(53416004)(2810700001)(8676002)(81166006)(229853002)(8936002)(2950100002)(77096006)(356003)(39060400002)(86362001)(478600001)(6916009)(7696004)(4326008)(305945005)(54906002)(117636001)(6306002)(93886004)(53936002)(7846003)(76176999)(50986999)(54356999)(230783001)(6392003)(38730400002)(110136004)(50466002)(2906002)(48376002)(105596002)(47776003)(6266002)(7126002)(55016002)(106466001)(6246003)(5660300001)(5003940100001)(76506005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB264; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT038; 1:tKtAVcG00FYn/3cMlmq6KG/CRThD/bKyGDtI6TNpKuCiQVkcVpSssbv7ldwi/taWan9ryz1knJZM57fIxec5UjjCnjdJzVd91G357eGJlG5qVKChDgw0V9yoPMCWU5Vo6Cuv7bh8/7kx5OeSk8w+VTxtf1Al3f3jJi+BbQQsTta3DoKbYuI7BeNvm3lbjOnEUzVsec0J29spHZXZKaLZ3ndIvjHlSOKomEFJ9DqdcRkGUkbRh3gqvubP3Ud6wULWJpTO+JZJ7QFyTAR0gPieacuFQJE3ss+Ym3RfrxGc0K6PgeCUzcAW6FEl1VN9o4efvISK6emfoHzcHV7rWlaxJdYT4/pbHPy6yXOqyUs3GmuuZDh1Exb6UXHbCdrPQ4ZaeraiOPgbA+hLpnOaNBebhjnf9u7Eqn6+8zPlY5WQjrcRhO/oGdCRaFWgeEWLkvodpP+ax7nmdeqKGkALkMLzDhoVpLPFf3VKzJj9VlE42Yx4syRn23aAXWhJJ2Ma8vv4ZknoXgmkghDvTb7dvwEVyfBf1H/eRbQsu0iTta4bGLdsOjZ/ulUSUVve9Mcmo7bTSbzzjN5YxC7k4vmL3/z5A5D7XmOg+UZtkMV/8Og3qWJ45kteuTLC7cXwfQt/KO9f X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9b757c3f-b65c-4fc8-2518-08d497b3d007 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN1PR05MB264; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 3:YgarzGIpQ2GR5PRmcH4GetT7fcxhakFJIfahgcgXFYvN98uWX9odSEn9nJMKcJwmIPvOwGCFCbNmZ2/+ZOF5ycQsQkgWgflajL4tj8VEEk0UTvH9rDIXFFbDc3VdvTkKkwLXIDTkQfDRccx4h2Tretov+n9TX27Q90PHlqSg7ykTpWH4VSeHfZ+jLGjtOdDBOURXce75CoB+KUiyo7UwIZ4jDLgC+C24qge7neCgy451KkqEanB2oPlYOoc/rk1ANo/ErZYrRP761eHun8a+CuAY1w73irRzIkUO+L/GOPFrFmBSQK2MifoSF3awRJA4HGGri8wlOuxXn0T7/X3LEHbxhUsc8yIwD+QfdlQfc9ISep2mRZREaPNz6QEciDgbOOUpWRYtBQ8A1OGivOPamKj1RYFnbmmVE/9iIF6CgBMPI2isPLWYsXX4Gzpxt8IfRO3tzoEQMfNlxYXXfDlLJw== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 25:xsVZYi9hwcdxP9jKRO6I597w6kX+ZAImlPeqQjl6M4dknQdWIglQo7uEhdJQleJcaO3vshrbU0D4+zCMCcmixCQtYCKe0ycnksQv0tErw5ks+9WJL2HNCJfyEJlBItCo2+/1CEmq4OB2ahQw1Gu/LAZHg4C0FtjQ++9c83sVrBHAnnGVSTFuuY7xy2EfKW7+KOJwn8oPxp9eohTnXlwDCAov5ttdfGcexv7N2tO5R+9+38o+fOJ9SiybsC9wdbKNsPaR00hi8SsgqTyWZgDS2HiVvZjf9S3jAoYyCobzVssV4nhxuLF4vCnx6/TL9zQZfjaRxnCww63C5p/lL6iojNKHvxqwBX7WIToDoV7c7uEd1H/3yE5lQC0O5QY3t+pXBh8uDeZZLaNsoieS0cxJXozqbqyaYfA8bCW5UA+asDDRyqb2d1zArv5tqdcZo6jwEfyn61WA9W7l+9BuTa0/xvV14gfR+o+q2EU1OTmRa3E=; 31:7pmeksai5L/+HU9k81fgJboU74Zif4ol5ZPPRXo3CSDTXJmQE0XjxVfK6DE16d4VYC+B7VVeKN+QFfScUZE/XixBCUD7DgMbBf3nJH/V8ZDEBNP1abzq6FCCM1EsNe0+5woofqglfLtfU//TmQoRNcZeWhJDfsZ/tRlKwRiJfF66wnp1ivgv932fGPw8SX0+iW5jDnwT1wkXjzh9SLDWKgxvX+LKR2lGMCZQ82LpRuvIB9CEm3BYtI+acpUbM5al1uFA/+CbzcU7fXUE0GrbCX71qiiG8674u9HV6JMyPCg= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 20:PdohRZIIfCcJY7NwRDON9z8x3Zg7RpP/FTqNxV5F82g2MMQCZHG1aDafuqM/jYV4vxeT2llWEK2cIc9Dawxi80zfWBXmrdGTqXfunHXB/Lub2sOoymPBSuorjOCcYRXF9pDqzyO+gcsuS2Hug2DhFY/f93Ro+/FDAbWqj1OCxIY8K3StVhToz1VjBD5tlcd1O/4c0cINFA8cmjQUXB+9D/TVLuHke+mwUxddZueH9qlXoJycSCkX89VeLz69sgVXPunFdWUboDBQ/mForBgR2SVx26Ivq79ENbKANSOYO77ETwfxbnlBLjrvTopzmKv0wkQqCWc8skfl6SMXUq8UlAvTE73UNFi7MErUH8mwtuSiq07JgLbx0YaPIsn7ALLdXnDgetcB9ChpLYJj2qpHfLnb6UtOnMWx4JTuFSsYWT21UnJxaZ72oa9hnn1+dCmr3OVP+AT9a+/Elk3eGLEMJMEHZ4fc3Bqzrr+81v32m4sUJzTMR/8pQT+iPiSVrNaN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(1591387915157)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(5005006)(13017025)(13024025)(13023025)(13015025)(10201501046)(3002001)(93006095)(93003095)(100000703036)(100105400095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:BN1PR05MB264; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:BN1PR05MB264; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB264; 4:6Sh1kVw7q9hgV8QSuKXwhfh9DELgk1+palwNCT21GDm?= =?us-ascii?Q?poXmntOWTVGy6VhGWT0AVK5Fu+OAm9zscXhCW5Y4WA/bN9RJ4ABnrTkWMcmG?= =?us-ascii?Q?9nl4ccX2Svz65l17nx5uWChYo9N/YpZYDfsfIdLqrafPjmjBXDVsKLX6DnPo?= =?us-ascii?Q?WfvzGyaJhGJBRy11xVDQCdnsFTAVBpJ0CY52/MhbumjKN9vPAzuvufGO77Cv?= =?us-ascii?Q?MkTaKnxEB7ajtIjLnULG1bBTLFD9U7ht56TmEEGK9qzLprL1OMtvK6szOk1z?= =?us-ascii?Q?gTI0sc1QtUwTf4JjL2sKnJxeWDjqEja5Y+J6uns1A1yXVm+ToPSn5almu/Cx?= =?us-ascii?Q?Zgn0b9IGpZm/tM6RRd8JOdibAU1HO93ogvdgXadxGb8visP6v0w7/zBPOkUu?= =?us-ascii?Q?/vtz+VogB7TV5imvuWGpScIybHV+f1Uu7SzldmwQksriD1pMQlMZgprIxcx/?= =?us-ascii?Q?k24jc6iAXotHktzmxsC9f+Pdyn4opT3C+agMBJsNodkE/uWdfNkQiJNdqtP6?= =?us-ascii?Q?m5q6ep5zF5YAR64iDJBw12cnyg1bElcwwMULSgE0Epv1hdWcv/JqhL8CLp+F?= =?us-ascii?Q?uDNQVN/CT1vqQ6fUA/VSjFizfhxSlYt9uZzZ1H7zEXDD2xfcHiUJKohTGQ2X?= =?us-ascii?Q?qt1jJmCTVxP0WHopalBJc3DxB/ohMBvMgoNWknjzt/0Ws4FYCMh9PkfW3aXJ?= =?us-ascii?Q?39V6Cp3EAGoDICDLsmFw7nFctHDiSDuTcCrPdO8At3oxpXCE1fKcl3GKw7Cm?= =?us-ascii?Q?kB333wFDHLYWpOrp6NZ8etQRi1L1qPjYFyuxDPp95Ktc66+n57D1gootLbq2?= =?us-ascii?Q?eD8J7VU3zPGp1wsInVvkPPPtr9fYur1cHIS7ipoVyhVL2UsMI+C8KWALP3fZ?= =?us-ascii?Q?sv7rq/VJPy2sDSANO0oCMkJQ1VPRPldAzTmuqW+r+T/K4YBFG21Q8Fe2cpUs?= =?us-ascii?Q?cNs1Uz49uUKU3V8LjM0dkfTUe5nTWKS8FCxN6M3xGYTAzaKbBYpo8+7N+tvB?= =?us-ascii?Q?v3FPxK2R5YQ3xfdVVCJpV2aOk3Z95UasrSWawAGK7vkm4Sg5KtlZTUFXxsvK?= =?us-ascii?Q?20Yw1g9ZUZZ1W7Use2Q+LmhcH1kFTVKDz3694gN0gnd0Wj16ebiKQgfzbZ8z?= =?us-ascii?Q?UxI7Y6708zuqE+t/wHhMhKgjvMmuizyCr0W/TNenNW7+8eAaAe8BEY+cG4JU?= =?us-ascii?Q?ruerHFQoKkc3iQaN9gzOOEi3li2R4UHlsgfRoqo2QHkSRErG+Gy8hBI3bD2U?= =?us-ascii?Q?2j2icVvMYwaCJIU4jlReJrLVorQfNTJ3GD82zdmglZvdjl/QdmP33nLDvofM?= =?us-ascii?Q?PypaX2PSWHNEVevyPmRvnqjKv5k1omTooaWYD4Qxt?= X-Forefront-PRVS: 03030B9493 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB264; 23:LHaANa/bSGUk223V7NwHLkfS61SMk4pMR46Ohs6dWL?= =?us-ascii?Q?w2HfdxsQHJJXZK66eqdnFwUh0wonBayEmzpMKnJ+bV/GaVT0ROj666zBr3wG?= =?us-ascii?Q?WYG5MwSkXI94JXMV0d4rwffxU9EGtdXH+fvXOINsOim8QI/eROXSDJa8Cwd/?= =?us-ascii?Q?UX7Gq9d2CPTRYePw5ICy7r+D5mRsALGQl1hzjOpnRRGPXbTg1vG7T+yvPbNY?= =?us-ascii?Q?QgoeUsELSFMeml72sZv0ppTIDGorsqOsZM4PeYTW5HlhzJcGURMxMsYVTnRp?= =?us-ascii?Q?qvpkoU+j0SmtF0T9/wHJEAGgiTn9WKfs0cF4h76+Hq7cqA9xZHJ3G8GYJiDt?= =?us-ascii?Q?TKFvPWFVvXYHgSKHbNzGo6y9GUb8n0z28h7AcDT6R/0Cmp8Mekip5n7rtBN2?= =?us-ascii?Q?KlbtWxNf5LJZtQHaUDS6OKGZ1ib3wCrgs2lJpg9RLP2QczKU/YfeKplICv8h?= =?us-ascii?Q?7Mlmji3TTVX1qsKBNWTohS2XQdXK+VwsjPDeqiLMxPoHgccH6YoYq8w8pHkN?= =?us-ascii?Q?2/A4l3hrRTDkQ58KdDvPdLPhtQJHPuRtfHZU00K7qtrDgoHEHeMsRr+8N5es?= =?us-ascii?Q?mwhgMuBqVSj1e7SB/9VrFcAvGyrJ8Eh5JfhCxIfbMEihnFbnDgikVbQXSFaY?= =?us-ascii?Q?e4Z7tmZDJkVu+c9edu3vRoWFe/0YdBmQtw7IQvz8cA5twgEeBqpZ6W/PECjE?= =?us-ascii?Q?UAWof2dpzMxPAvhIQTTWECsNTx3FASBJMAxSYvpQr8rkKV92vY43hqBF5t1W?= =?us-ascii?Q?Wo6uA/Qv+qBRan5IianaPhojx2IirL/6+x8v1krX5bH6FoyPw+S5DPBVRG4H?= =?us-ascii?Q?cwjELz7mnpYE1Egi2yDRYPnGaprAE/jraUYy49/o9LLoPDDoFmxTQNtcjePo?= =?us-ascii?Q?fdVIk5jaM4sKypUs6/gHzcX+QCp/g+VYshcvIaH5f7gpi5fVzN3dIgWtRs1W?= =?us-ascii?Q?kLDhCAzhkVsukQGOdVM4TfRv4s3Jz9jkAZn6KzUlWSH4wuDy6BNnkSCKRe+R?= =?us-ascii?Q?YjdKDqVGcVC0SiXGW91hBvEfIixxABmlSZGu8aqAW/QDG6H1TOkrZa2hEzCN?= =?us-ascii?Q?ngyys99hsl/+EkBFu2aohmtQXzw9WqEDU+R0eswUuZxqC12qmpJU9UVEZOd4?= =?us-ascii?Q?9Q6dbgY457PLzfS0ycH4f6BtPnUo92tzRWI0KBmAeaIIUL51enBdGhOlyrlE?= =?us-ascii?Q?fansLRq7+UIsaZP5oVE/A+qitr3ZZ1BWfq/jVIa9ofgQw3NQMaTSFfkh8/1c?= =?us-ascii?Q?CD9xYekUxHn5lR4EkreWsAG8ZySk5luWn11uhLBbY3Ze+4R9upvV7hfmg4TE?= =?us-ascii?Q?Hj4DZf24pUo9kqXgxV21nMo+vvja4WIpz7z6nUj1W2aBC8tDj1op+mEDpC3z?= =?us-ascii?Q?+xSg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 6:IUnXwgwP912QzAU6i6s8ruo0J/b2hDAW5oYUhWppq3Hpb4BwgcxzuFDont8lThN4iLxz0FZJCzp3jl6sYEMozm9+0xFAHgToHf3OOba//VseSO56gErig7/fudKqICO1csP+55L7UsIF7FO2CmRHm7Pj/PmedsqDembyXTyfwoueT219C9gpHpJ+icMbY7Yp5ozHfY1lDSGkoEd4PYUlKsgJT5dN6ulnnvNp8JafrS/oO0Hmr8qhHZP/SKVU591WqzAxojlrQrk0mgk3IZGwcchfve24VDglUXB/Px9sgwgUoVsFg8qm38oYhbmXLA8bAfzWdo39QGNwZa2MDXP3UW1WGd2ILECeM+UH+G2ANdWXPKpuLeDf9LuOd8kMGIglfLTK9wQ878WoWeyHGMuze+tHjLMCRsRkbGoxXhhsK1clyp40Oeo1cG1fJ65rHoArqIBLBfQ0t9qdFFhPpa8hmtQugz+0tXZjxSF+qhi6oUReDnOt1LCyOb2eAJuboEjVxJ5nQ1hZw4Z8GLLXhWS+XNAKzDovBLoS7c3plfRxoj0= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 5:m5hF/JAqMlEC8BRnEwGItrzUfxtZft7zkK5p+zJZSnlaMda4un2CjGrUxBahZCDnhNVccBx2ruRCBUP3/hfwStTlfiLHWu+LtrPla2l9fTBHkudfr6F9EPr5P124U1Q1QwIRicjecZ+Ph4YkllBgFAicu5h/aKyw/Qf/1IbI5kX67OvqPg8X7nXcqHsicruNhm8crrniS5w3vaViYwqLWyB4Su1Fd81NNOARj9dZ3x57LTBQUkzfuxC3f2t69OAMgZl7OwEQTl/tceyNJhdwb3ZTMz4rjRDDpLzb1kJm8fPIjaDIn1p/Wwl+WPze/A1MHpHRs2z6PK3oYUrLfWrN2JEfRjraE9XjqOekLzayVkwIww0Wggx56c/nRt4pGoLSXLgJpJKRYIHagg3CHZMQ+aOw8Jk4OLPhUNr57tbYAc4+yltwD1WYi0O5bGYwCLdMky+6Z/nLc4JpkCQWPBkvJsmwOJUfepruhKKxOEygdyKBq3wqu5RcAjQrTnJx97uU; 24:P93FUBc+ml+fpG3JA5zFnV8f16slloBdQXa2VqC6PwdQTN3crsJNa5k/gcqXfACeZXxLdchSI2WSzoL/45UcU1K723yOukOM5k6P5Qowx+I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB264; 7:D5LPDr07GQBO456D3Om/41DEnTNAswrbtiWOlE5eib/b01W7dPZrT3J0cQv5ErRmEhocmz9MTs4pO553fcdtuS0D9cIqhbzdtdX+TfzPCFJSetz6ORlQnedRXDN4Bk8+X0p0SDy3Sd/vf8s60nzyyEeBDUn2bQ1d9Ns7kDxootSAWr6Ha0ivHmXpdHhdtzt/Zi72XbS+w2PGucDkyZ1rbSrrsG4suKnhf7PKAVCOiY/weqAPk3wh7BP91JOg2euB+upn96cKyCSTlfT7UazhiTXWp8Pxm2CgbO08DCIDSuU0kvMvSN790D8CcZT3prlKYTloQstT2CxWJOMwtKMVpQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2017 14:49:50.8404 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB264 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:49:57 -0000 Jim Schaad writes: > I do not believe that this has historically been part of the IANA > mission. How have OID assignments for RFC standards been handled in the past? MIBs do exist under the IANA.org site: https://www.iana.org/assignments/ianacharset-mib/ianacharset-mib I know I have seen MIBs with a copyright of "The Internet Society" in the past as well as the IANAifType-MIB.mib with types that are prefixed with the 'IANA' string and ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" inside of the various MIBs. It seems imprudent for there not to be a machine readable record of the 1.3.101.100 .. 1.3.101.127 OIDs. I sort of expect a section of this draft to have the OID assignments that may be extracted. Something along the lines of RFC 3560 perhaps? id-X25519 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 110 } id-X448 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 111 } id-EdDSA25519 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 112 } id-EdDS448 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 113 } id-EdDSA25519-ph OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 114 } id-EdDS448-ph OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 115 } Safecurves-pkix-0 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 120 } along with all of the other book-keeping needed to deal with the reserved for future sub-registry and unallocated 116 thru 119 and 121 thru 127 values. If this is all wrong, please feel free to suggest the right way to do it. -- Mark From nobody Wed May 10 08:41: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 259DE129C0B; Wed, 10 May 2017 08:40:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149443085411.24397.6934950344832791952@ietfa.amsl.com> Date: Wed, 10 May 2017 08:40:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:40:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : 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-05.txt Pages : 6 Date : 2017-05-10 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 08:41: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 52B5B129C15 for ; Wed, 10 May 2017 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 jku0SoIZ99Jr for ; Wed, 10 May 2017 08:41:13 -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 5FF13129C1A for ; Wed, 10 May 2017 08:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C0842300545 for ; Wed, 10 May 2017 11:41:08 -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 IuypDsIZP__u for ; Wed, 10 May 2017 11:41:07 -0400 (EDT) Received: from [5.5.33.188] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 581473004D7; Wed, 10 May 2017 11:41:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> Date: Wed, 10 May 2017 11:41:08 -0400 Cc: Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <8021D75B-504E-42EA-AA75-42A8F188EF3C@vigilsec.com> References: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> To: curdle X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:41:15 -0000 >=20 >> TECHNICAL >> S 3.1 and 3.2. >> - Is there some reason to not prescribe exactly one form here? >> I.e., require id-sha512 (etc.) or require it not be there? >>=20 >> - Also, TLS has converged on talking about an "identity" hash >> for the PureEd forms. Was this discussed and rejected? >=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. = Eric is suggesting that the =E2=80=9Cidentity=E2=80=9D hash could be = used with Ed25519 and Ed448 when there are no attributes to hash. Using = ED25519 as an example, we get: >=20 > IF (signed attributes are absent) > THEN > signedData.digestAlgorithms includes id-hashIdentity > signedData.signerInfo.digestAlgorithm =3D id-hashIdentity > signedData.signerInfo.signature =3D Ed25519(content) > ELSE > signedData.digestAlgorithms includes id-sha512 > signedData.signerInfo.digestAlgorithm =3D id-sha512 > signedData.signerInfo.signedAttrs includes message-digest =3D = SHA512(content) > signedData.signerInfo.signature =3D = Ed25519(DER(signedData.signerInfo.signedAttrs)) >=20 > Do others think the use of an algorithm identifier for the = =E2=80=9Cidentity=E2=80=9D hash is better? The current document include = id-sha512 as a warning that Ed25519 uses that hash algorithm internally. I would like to hear from others about this suggestion from Eric = Rescorla=E2=80=99s review. Jim pointed out one possible downside. = Others have been silent. Russ From nobody Wed May 10 08:41:55 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0848E129C13 for ; Wed, 10 May 2017 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoNTBOV3kqhb for ; Wed, 10 May 2017 08:41:51 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0108.outbound.protection.outlook.com [104.47.42.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBB4129C12 for ; Wed, 10 May 2017 08:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2S9r2JY5omYq1lf/KG5M2LT7DEeEGx/WLmQDoNZX3lY=; b=DRWoAoxazSKgGQX93OMwc38EZvaqsgt9pM9eyxrGXY72OFTPnlHq5iohU/X6Gfyh6AU0VXY81o8lNI7e7fl2mNRxQK6Nfe1DAkSwOpLgOd/ZQXz17qt1jXy9B8fyUj1moSxSGUAzldA5uJecz7lnS56FEidUL3LNuGTDU5TG1I0= Received: from BY1PR0501CA0026.namprd05.prod.outlook.com (10.162.139.36) by DM2PR05MB269.namprd05.prod.outlook.com (10.141.100.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 15:41:42 +0000 Received: from CO1NAM05FT061.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::209) by BY1PR0501CA0026.outlook.office365.com (2a01:111:e400:4821::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Wed, 10 May 2017 15:41:41 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT061.mail.protection.outlook.com (10.152.96.179) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Wed, 10 May 2017 15:41:41 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 10 May 2017 08:41:40 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4AFfdjM012946; Wed, 10 May 2017 08:41:39 -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 65C5A11446; Wed, 10 May 2017 08:41:39 -0700 (PDT) To: Hubert Kario CC: In-Reply-To: <3354972.PP4v7qzrL4@pintsize.usersys.redhat.com> References: <149221433384.15894.2426718340325647925@ietfa.amsl.com> <3354972.PP4v7qzrL4@pintsize.usersys.redhat.com> Comments: In-reply-to: Hubert Kario message dated "Wed, 10 May 2017 12:26:47 +0200." From: "Mark D. Baushke" Date: Wed, 10 May 2017 08:41:39 -0700 Message-ID: <11977.1494430899@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(53936002)(6266002)(7696004)(2810700001)(50466002)(86362001)(7846003)(48376002)(55016002)(47776003)(189998001)(478600001)(229853002)(2950100002)(6916009)(77096006)(5003940100001)(117636001)(53416004)(76506005)(230783001)(7126002)(2906002)(106466001)(356003)(305945005)(105596002)(5660300001)(8936002)(8676002)(81166006)(558084003)(4326008)(54356999)(38730400002)(110136004)(76176999)(50986999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB269; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT061; 1:4OHbAU6+qUjwNPGpT/HaA0F20C3LTVbbIY+uyUVkYIKIndb/07MwmDzw3iO/d8gRQWHDnr//TXySriqevc2IeFYXqF+rtsGj0SdeN5dR60PkcSxaMrlwKO7S3+Qv8teUECdUYuS29S/iEW/aPsyJMIpSU2zXs3KotTbMOY/qgF84IinWSmrnecl6y7hHOLJ6mLEMNyBKm55lHGC3A5Y+u+RciXizgtz+uYg66c8ckAvKnZs9GPu8NT7ccFYiezexoSaIbcNiX5CaASZ7Gwm0mBTx7TTXtFOBo/iRR7vj/Yuq/1/gD72bZc7MgqYFQshra2WALt4+fIeMWzgwcQUUldUYMvgp5KaRREOVDJFXeHHiNMO/3J2W0D0M/kXoXXBfxJHJZLxs4EezBIAmJGUu7acUgbtuuUTmvrh63sC6V64h4HcureKImN5XCbU0RN0NKE/gEOHEXIplGCGjHjGZvZJRFTdcW/oesIzmE64HPP++4+mSbxoQcw7Neh0ohgtN7Kdfmemny9qKVKcTTqHdf1eDlvPPXX3pIriu5UEQH+R6TaCJJx3fP4aIgqCeeMjOLr0sPHHTo1TRMHBZ6P1qIy60rsEpPuJ8qt8ofLShr1c= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f1b03e6f-2798-40ac-5171-08d497bb0e57 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR05MB269; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 3:IRklVIF3LQDcR0VceBBdQ2jwo27Uf1w7yBaJEVtKCqh3T7EcBeMg2QWiK97/wfcjLMtjPwKwF80KCsOOyu/qwHlTW55rHmpSjQgE/z+MdjBhqzWoFcvetTSHWrkxojJXXsqzNxABkJ48rZFu+444mspxcIOmxq19nowAnWq6cY4d86A9Kz7D5AytNCbt5UOJ2ACsdq0D1pzbocgmgfDJctvDDvS4luOzBzCRcnsDgc7je0NzK5vaFF0w7LIhq2/kCGYo0ex2Hsy55yIJFT9QLtmPfvnxH/pTTzg2agCOyeNmmHwOuU/WpactUBnuz19e5TxouRi2yZxLrPtZ2XIiJ7QD+2rR1EiZ2iIgO9p7vUhmCZIAq7+IGdRl8O3v0zMS1aJr7ACdPRFv0mvUQEoknmsuxl4Jdkpfj715Ih036KkCQE/2KkquT3n5h9XPPm4KCPGgSdbx2LJjle5a2wkP1g== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 25:sHzDdKvNmEWYZPTgEjpBio+jOnGsS1UdrjvXfepYUAbT6BgJZng5oXtdftqJN/+ijTBZqmtf5oIm/uvi9Hrt73knIERPcVvLtlKR5HOeDx3ycfCi1v2GcpXaCDbvpRBBD+JmAuItC+E3OzyFLt+W+fs4A2jWjPIwotHEdq8uFoSv3qxSvyijrRYkf93Hd955TZBBiVgrcylNYQ+Og1uH4xwAnNPJvlm/sQDWjwkke8iga/t+ks+PayxRfpA2W0bad2SIOC85GDpVKRMY0EOROGUDTGtl+3XI1qzSb/QsppnN8yyMuUm4wKi8FrPa/XzoRC/Up6Ti7drb4E5vRgQK9vU8IzPE2D0PbkABBGkG13fuKKhStZTQor58bJrXhS7yz0ZXFPvhxuN7xh2asZMmgFwJZXZDyaNNr9Gmm3APCJEPi7WteG6ODR1Y8gSI9wuEEo6HuQNdqHFBueSt41H3LjdTeOfGaYY2gqekiknS/Wo=; 31:gUnG95aA/BxaVhs9Jvm2f2PDqKaCJH9V1CjIN69kFV1b0RTwNgGEVUhsQ/ObXJ6/ZBwftjEV1IJj4ouW9K2xHaQTLxey3Sv0kniFqJyrSHvwKHB01NiW/sp48dlfE6sGFLg0O9qj0Jhhw+oLXDc7aexjlts33Tn6Ynv9nGEvR1jAhr0rsgJLLkErr74TKORx6BN+ORYeMcf8pK3W1TL3zMg/8CW28qTGP0AwXcNq1tUN4pE8uRDfd2SpEUCS93AJZ2pB8+mszTJny0S2dDp7Hw== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 20:dtdLk00wq9u2UjCZfgmJencuAG76Mv3P8kEpjTbZT+VqKDiGjW+VcvHtMKbwAYWW31xdUcB7xVnVs3YDz01fPikceCTlu+f+5UTNem+gHb70KzIYRNMKnr/eT5F5PTbxLMMs5wBFJfPoRFHpCiOq2TxjlIxKR+6w1EbwYj8QwznHZ2L729W5qbhgbQvtSZEUP6bRVi1Cqw2p4EPtjEi8AeSPhkHAUIamn01p+3EY9el30njF1UCDyGssI4sa2FQsWG74QXgrl0DNDpAEmgkzUj6aK7cyJggCFI7ZR/fX5CuYl9kOjsLwToFVkumRS4ISqO9KHxw1xNwuVttCd9B0fjX+meakq/c2y+j4F0KpCnK3DW2Jz4rXsz/gfLDAVp5Hvdxg2yR2FRZDe4LKRHeoXyGmIHhh5DBF7KP8YEL2pRGvgmzMBzO0o6LpVUI1787o7SuzsYKTLs07pKalNMyL10Jl7audIHdxQGfD3ZJc41KwoVf56mdx2GbmUVceprGW X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(13023025)(8121501046)(13018025)(5005006)(13017025)(13015025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DM2PR05MB269; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB269; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 4:v3AwVaAPDZmHFZ/pAcQq6CGR5O5mOcj/Haxyqx6V0SJyD5HtTDS7CgRpkx0iObYRBTRiLLqRiPkSwt8iujTeL1YFTl8Q0tIwdZ4JVY0h7WrwYl9mCGbGJ4YmgTq+x9TAcjxqnBs6yg93Hka3Dt87YKJA7H+mSnsWFJGrKBU50rw4hv4N5pe99kcuolRuGOPOGz9+egSeHISBu09aYX5TZdAejXNa2DZFxAKYf00eNMWkd6TBRsLlVRIfaZfkTFsFlDOLG5hQe6KfjEWCsqGo5e5LyFwQ5Ew4VHPF7Dcq8axfuwQQG8AvJXcIixloJHZQ4Ng8uAvrGp/WI52omEzDxuZT1nJu70brCJNTv8Gslun/469FO0V2rixErKQPxGg9oW0sQCbwWCAG3ZCJRj5Hf3s+bv+WIFRWBVIruyKt1HWf6Q77SCCymO6EI+csHMjUU0a0tXE8Ox3S7DOcGWASwj8mToazwcCHogtA4eHpZLfzPEtDq5wT6aZOaMSjkBFiRLVOoKZ7PF9UqFxu4KWby0Kp5jJtgIxT9jlTXxou0i5a7YbHICvDkh4HGqQ1ZoZUJ6lg6aoXzsNsQgX9gFhKKSfe29JFjenNBVOcG5CZZ6iGbieEtvzcL6DolqGCdYmIkXRlwk7R45RPzyH6XnOEmSkkOt4NcuPAYIV0n6yUrluxMjv0Yvu9//rItb7yPnU1mPOO80CDNRWgOldPMfTHmjSpT8hQoQif1Lv/OUmvCpD4jnVAEUum2P9e1aiqvkNyZavU1xKao1ONcJEth6uJWzOqDy2o1kqM5z0i7VhcnBd+NCgod0cO2rZ7AIkxKiy7RQQUrzQzVq3563nHc8+PMEtHpe5PHWWwws0oxe8es3Yqu7sYGrj/OBjye+AjUabLgk+3waZpffYNgt3HDo7sgg== X-Forefront-PRVS: 03030B9493 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB269; 23:lwKPVjt9QbMbP5bBYpK1z3nawziwduf277L3Uhz7IH?= =?us-ascii?Q?zmemMvbp6qBcpnMqoau9Z1gRro5vruBOVC5gaTRKQClzZDu31m/PrACJhvvA?= =?us-ascii?Q?6tGC/HDprMd0q2ZRV8N6pg5cCuxVC6ZGPLuHYrzUZ83DHbqIBvjkQzMxeS7o?= =?us-ascii?Q?eDC1EB2PdC3qVuk0N9O5XDtBZ3v5L01GZo09aG8m5PY2dYFm8xQPXDAvIQdc?= =?us-ascii?Q?m5cO3Y2ts77XJTfaOc21kH02VozInyTCdEN46UClJSHoyAWIvlbx4Y2X5U3M?= =?us-ascii?Q?oqhMxl3nJJee1kxH7Ec2EpQH/w/FzTzViwoJxmJFZmT1dLdneEsVAblUWaqh?= =?us-ascii?Q?5wuzWPQyRb91uzhr8vV9nAxCEktU37q5fKgIR7dkSLCyUJduttkFnTBFScez?= =?us-ascii?Q?q250iBceqzMNgIdzwoy7MK2QGyYXvazoiKkDRonccWdfDSmsEfNuqNBtAvSt?= =?us-ascii?Q?wIzBhjrQmgcV8BSZcwp+isJdCHBaF9YGst1zzdUJaCmaAwhSHM8vaJ4eMtP2?= =?us-ascii?Q?GV6qAdGw5z8s9QLKWNF3siTyICTI8H5gNio0HsNWfxAJqavbq6N20BPQEGq5?= =?us-ascii?Q?0lOGnwOLqoGOtZPl4SnZBQN93AUIW2SOsAPmklgKN8CYclymvTIByInUOE6a?= =?us-ascii?Q?n6VdldWvY2+dnxL2P0YheHGctU8HSZd8nizkJbZQIpBKDmtXjI88QJoSmj2V?= =?us-ascii?Q?y9fdjR4KWk9gWGyrYw8xJy8qKIVDStKlBfNE8BEQcnpaCkZPyq5IO5BCGJh0?= =?us-ascii?Q?lqUygb8F0JhhwVMxbsW8lNPqUeyxPqVZE0PSk2F2PYKla7OAg8Lvm5+Gcy9o?= =?us-ascii?Q?NIsk38hxTXwvHTe3sLKSFcyYSJ1udG2Um4UQTdltOvSQ3x+9B6ptOqVUGb8F?= =?us-ascii?Q?YJ2G1v8pIUnbwsMvr1nr3tp6L63U6OrrTl7/6wnUjLoSqlRbm35d9qr2Us8K?= =?us-ascii?Q?htG22wk6hxC/eEfTa+gAmX8z+kdIg4bgQCLqb0TQZFrW3B5yEEfTRZ9StzCw?= =?us-ascii?Q?0qOZQeFlXQ7d7eF3QzKgdxMzZKx682vnegwpq1RMmFRPQbYI+G9oSkJfrORh?= =?us-ascii?Q?MstZsmSDRpmA1R2sYOfSyAxhLh3VdWTYAvQIWhoWhki1miuiQluJNYwgUFBR?= =?us-ascii?Q?mg7IYuGO17nfwfnRXegRuYzTiRt0V4SjvmIJ6DX2Yg1slP0We5nkuvji8C6A?= =?us-ascii?Q?rZ5wRyFoCrJRaLYVDDrmrJNecT7O4LBozUZ5opDAh7Z7Cu+Oa5i192URrgF8?= =?us-ascii?Q?q8Abio3CJ+pDlInRQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 6:qC3eyZpgTV6xZKV2/Dexnh8/MKMg3OKMKupsXISmVMBmLqL/IcHGaZCmk5fnAXb37uiBk+UkQv5ZaV9oG4pCff/3riKPpzIFblhkUPrzDXFUUom7bFkdP8XMEWDRXlPecEcn8vadxTcXk+rRXa1qHEhsjGSJWYSV+UIxrskycRguZYHQYFqhPfY2q1Tibc5xB4AhqMhZWJdfrHxx37PdjcNeEl4R6IyyR3sq8cSFepFFMGRJMgrvac4hRvS99sPgP5ih2ZgzIaDRkCOqAtrihkZ9qGVPRzyB8htyI5wdllT9Yek1zVKpotucdnOCmW/pTiuEve6dMExYMLVU91pEhyk7zJAbyMGPR/0VpGkcNzV0xDp32v8y2mJHSPHcJG05WLPWNNQKQ+P6Bw3ArSW3wp8Za2Hgs8uzR+XZRu+LdFSYpBBM5YlsGpBjzOv8a/m2jpOee8z3TIbkM8RVWlmjQq03/O0Tixn5EasFlq/oqBY9U4aPfp0Ta93AM9Dem+F1DyJE4ymsE9kTKdgo8zstxJMF4VWCDnLoEV1euC3rASI=; 5:eyOcEHVp2NNzKFBz+ucg4HAc83f6/CRHHo6CWXXVbsjJJuJPe9FlyfIsnVFH1In9DeejBqa8RzP2suorx4CEs7gLD6QnVNDXRLHauymsgrIuLAxzFYPF8MYTNP3T4n/yMkNB94aCIu/xG9JGaRYTrw==; 24:woVV5JROzPO1gyJnr7pEW5RE49kNtRCRBzBSadeTaD6yeb7i8uJ3zAkvpyLs39MbbQBkQyJG0Q9AfilmVFMQT7Mf78sIGve2GgcwGAspdyQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB269; 7:pIx0SWiPe3DeOuDvCCuB8eEn5SKblVF6sT3FlYVl8bonBPXSNT16CwTsKaRZORYSns+jCPy8TVwqY749KqUWA87x1In5anh38fNlaJwcq7ERBDMcWwAJceT0aWMDtcaBCMGpbMhS9d0UeIQKBPz5BJ9upHSqDvftVCKY6w+k8uo9yZX5XDet6uRtfpgs1wLU4YadMHocSjjKTCDEAoxbBe/rypgY+ls9qUBcCDGyTdrvTuGIDn0DxsqmZQFzAJgakMTdhY1FunwocgGT4Es2yfx+snffSxOTcptSpPb6vDC7hOV9lAhtzr4MY2gPs+J+ycLhzaRGube96jq/V5JLwA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2017 15:41:41.8662 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB269 Archived-At: Subject: Re: [Curdle] Typo in draft-ietf-curdle-ssh-modp-dh-sha2-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: Wed, 10 May 2017 15:41:54 -0000 Hi Hubert, Hubert Kario writes: > > The group15 through group18 names are the same as those specified in > > [RFC3526] 3071-bit MODP Group 15, > > should be "3072-bit MODP" Fixed in the -05 draft just uploaded. Thank you! -- Mark From nobody Wed May 10 09:04: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 DF0B7129B82 for ; Wed, 10 May 2017 09:04: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, 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 r7zdo8jo27vH for ; Wed, 10 May 2017 09:04:08 -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 D1EBD126CF6 for ; Wed, 10 May 2017 09:04:08 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4AG3Z0i025321; Wed, 10 May 2017 17:04:07 +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=VhFXDzjiHELCOHuhePoygvNtpX4Ha6zj0beGJF8XCPo=; b=MSP7juCsReG8Knf2D0uTbVZBeqfCEnAX8tRgIbkXIZNxOnRqhgMj+IcKdW0eoV0rXKPu Yfy021NjQy7NDNoxF3hvHE4LgoQBZki00jVpJl5ofv+0O4PcdHIle6HvyJNj6TV9A4pZ EbQV0EZCmvw4LCoDH4TP9GKjOrRVY+tNrRcjz07qowGVd7o7XpkrzkW2hYKhLWOkpQbf 1/zXUK0x+XJVOnYAoKWbM79SXiIlmN4Xc8pDNxlEaY4C2J5gC0DCZZ4jleg0YRsstcIo QuHzZdQ14phbzfn7H510SZTsp2wO0yP0W4odzYArwyJ4I1PM0dT5R476AEfxfJ46DyAe YQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2abw5x34u5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 May 2017 17:04:06 +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 v4AFjqOr012381; Wed, 10 May 2017 12:04:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a99tufmcx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 May 2017 12:04:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 12:04:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 10 May 2017 12:04:04 -0400 From: "Salz, Rich" To: Russ Housley , curdle CC: Eric Rescorla Thread-Topic: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt Thread-Index: AQHSxdwqnBt4FwRyjUOAojOBRaXKVaHq+XWAgAMFjwD//8MfUA== Date: Wed, 10 May 2017 16:04:04 +0000 Message-ID: <0896a082b594497dadaeb2f7fbc6b901@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> <8021D75B-504E-42EA-AA75-42A8F188EF3C@vigilsec.com> In-Reply-To: <8021D75B-504E-42EA-AA75-42A8F188EF3C@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.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100107 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100109 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:04:10 -0000 IA0KPiBJIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIG90aGVycyBhYm91dCB0aGlzIHN1Z2dlc3Rp b24gZnJvbSBFcmljIFJlc2Nvcmxh4oCZcw0KPiByZXZpZXcuICBKaW0gcG9pbnRlZCBvdXQgb25l IHBvc3NpYmxlIGRvd25zaWRlLiAgT3RoZXJzIGhhdmUgYmVlbiBzaWxlbnQuDQoNCkFzIGFuIGlu ZGl2aWR1YWwsIEkgYWdyZWUgd2l0aCBKaW07IGRvIGl0LCBidXQgYWRkIHNvbWUgdGV4dC4NCg== From nobody Wed May 10 09:18:35 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537FC129C3F for ; Wed, 10 May 2017 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz86Z_FH-NcR for ; Wed, 10 May 2017 09:18:30 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46A4129B7A for ; Wed, 10 May 2017 09:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9LR1jh7Y8ILJ3AtRCwJ57z8LHtDnqEmvUJQDfYfRJVw=; b=TuMVqdLPhmNWRgWGTd3S3QYrQBuUNtWC+joIEpcoDoEq0oUvoG2EK7V14EgohDa9fTPqNpCT7qIKLgPj6utWQtkUhS+eKFvF1SDzKEcBW4aQbtmJCo0vClh5aEjb2+z7Pc4B19nbrlDRpifqETiDWJYd2HFelyl60MZL4iIKC0g= Received: from BN6PR05MB2916.namprd05.prod.outlook.com (10.173.18.137) by BN6PR05MB2916.namprd05.prod.outlook.com (10.173.18.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 16:18:29 +0000 Received: from BN6PR05MB2916.namprd05.prod.outlook.com ([10.173.18.137]) by BN6PR05MB2916.namprd05.prod.outlook.com ([10.173.18.137]) with mapi id 15.01.1084.017; Wed, 10 May 2017 16:18:29 +0000 From: Mark Baushke To: "ietf-ssh@NetBSD.org" CC: "curdle@ietf.org" , Eric Rescorla Thread-Topic: ssh-ed25519 implementations Thread-Index: AQHSyakPmB025K0AyEG1vsM36lGUqQ== Date: Wed, 10 May 2017 16:18:29 +0000 Message-ID: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: NetBSD.org; dkim=none (message not signed) header.d=none;NetBSD.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR05MB2916; 7:7gnGkpz9aQM1h14FcAYB/Q69U2YPThT1C4zvBUF9xlboB2GVAeAVRH8GduxgoLr1BGtL2kDEjlaFHVj8ssJ++1m7zPOWU83gqXzQAMD74wbiVIrnfJ1NFeLP2AJBPQNH956jR3gG0Z5fVgsD7IjFH1ODZqRRsufP8gLl2ALziFvViScSBNYt5PGakYS8+84CeaEyzDjz7vc+PpJ60X9uh6PTPtGDGdbgIcmchrsN7W2jix6gw831WNs6cEpJdK2cbByDDOoOHls4jmc9TP0fZ6mdZ7p6bwA/i21yxZZgovcMcf5ghipDJP6EJ2pLx7byDySMCdA0uQ8lv8zmPnduAw== x-ms-office365-filtering-correlation-id: 1d95b54b-32b4-45d3-5db7-08d497c031df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR05MB2916; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:BN6PR05MB2916; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2916; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(39860400002)(2501003)(2906002)(5660300001)(66066001)(82746002)(3660700001)(3280700002)(478600001)(189998001)(6916009)(83716003)(81166006)(54356999)(50986999)(4326008)(8936002)(25786009)(8676002)(38730400002)(6486002)(86362001)(6436002)(2900100001)(77096006)(99286003)(53936002)(7736002)(305945005)(36756003)(122556002)(6506006)(33656002)(5640700003)(2351001)(102836003)(6116002)(3846002)(110136004)(6306002)(6512007)(54906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2916; H:BN6PR05MB2916.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2017 16:18:29.2029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2916 Archived-At: Subject: [Curdle] ssh-ed25519 implementations 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, 10 May 2017 16:18:32 -0000 Hi, Eric Rescorla has brought to my attention that in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is currently specifying the SSH encoding of secrets on the wire using the mpint process as described in section 5 of [RFC4251] while RFC 7748 describes using a little-endian format: GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + This seems to be what is being implemeneted for curve25519-sha256@libssh.org, so I should make an explicit note of this in the draft. However, I am unaware of any curve448-sha512 implementations at present and would like consensus that it should also follow the mpint method rather than the RFC 7748 method. Please reply to curdle@ietf.org with your opinions. Thank you, -- Mark From nobody Wed May 10 09:21: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 562C9129C6D for ; Wed, 10 May 2017 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Sd3GsoAnjP for ; Wed, 10 May 2017 09:21:18 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 BA989129C64 for ; Wed, 10 May 2017 09:21:18 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id p143so169067yba.2 for ; Wed, 10 May 2017 09:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v5q25DHV0VtWSwMMM3z71duY/zhjrRsrpeNjuvpEKHU=; b=hQqf7Ns4qcUDjC+y9g42+obT1yRyTHGMZAM8hmf2UzbxJQvfb/QG6tRf3xJGW55fda u2k6TpQY/N1E5HwUDU7iZnr+nt4jvBCi8OCvsiVMrjJMsZJXaCKWD9csi9i6DNG7o18h iLMkr+haiTDPlXQkNyrdIEpatK6B6Vvxi96K7pEqFIpOK+uWOJL5VjQ+nCfAvUhXP4zX KjwZ7VRihtDzZITHf8UuGFk0G60n17nUckvagfIamCDu9iLRba0GcC03SwWGcd9F+nko JE4Muh3MktRUZsPCI3MyscPA6nuyMxKL30WJSyOO3KFEOOriZ8kjVQjcHDn2+FJRTwWc OTmg== 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=v5q25DHV0VtWSwMMM3z71duY/zhjrRsrpeNjuvpEKHU=; b=V4uR53QbFdSjyZLvfFoOzNV/D6LhhV7C9doe9ZNmHAF+H+sKWvTodDQ3bwQupt9VYo xSuXuBngIb0a97Tk02VL01WHIGHktAyLpEXZluwJ+B2CGj+kW0fnkLSb5VxFqX0BEvIc ZL86GWhl2g7aDkKLoA6PiIfZmKQ/NaHX443trfNnS23wgGx6vu+iw8bbhpbhoUgcCD7z g86SnU7DqRPXv0RBnUyqqDFpLFzJ8EN+bs5VlXw6iqg4qNaa6guA9WpIn/umf1z/SEXa 2U1dzlqf91YcrFShWH8//4+GJRtWUUxrK9V0Go1/7JZ4lLruFQZMrmad+GonH4IYJWqM 1aow== X-Gm-Message-State: AODbwcATcSrGd02mqjSW4e0E4SCbYdRUbZWdivdLrLFoNbDXLJiJ19+o VAgHwngDCp8zt2n0Y3xjkMUOecY/GQ== X-Received: by 10.37.218.145 with SMTP id n139mr5487597ybf.117.1494433277914; Wed, 10 May 2017 09:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 09:20:37 -0700 (PDT) In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: Eric Rescorla Date: Wed, 10 May 2017 09:20:37 -0700 Message-ID: To: Mark Baushke Cc: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07e820abd3f4054f2ddcac Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 10 May 2017 16:21:20 -0000 --94eb2c07e820abd3f4054f2ddcac Content-Type: text/plain; charset=UTF-8 On Wed, May 10, 2017 at 9:18 AM, Mark Baushke wrote: > Hi, > > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. > Thanks. To be clear, I'm not saying this is the wrong thing in the draft (though I do think it's kind of an unfortunate outcome). I just think it's critically important to be clear. > > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. > I tend to think the 7748 method, but all the options are pretty terrible here -Ekr > > Please reply to curdle@ietf.org with your opinions. > > Thank you, > -- Mark > > --94eb2c07e820abd3f4054f2ddcac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 10, 2017 at 9:18 AM, Mark Baushke <mdb@juniper.net> wrote:
Hi,

Eric Rescorla <ekr@rtfm.com> has = brought to my attention that in
https://tools.ietf.org/html/draft-ie= tf-curdle-ssh-curves-04 it is
currently specifying the SSH encoding of secrets on the wire using the
mpint process as described in section 5 of [RFC4251] while RFC 7748
describes using a little-endian format:

=C2=A0 GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u,
=C2=A0 in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... = +

This seems to be what is being implemeneted for
curve25519-sha256@libssh.or= g, so I should make
an explicit note of this in the draft.

= Thanks. To be clear, I'm not saying this is the wrong thing in the draf= t
(though I do think it's kind of an unfortunate outcome). I = just think it's
critically important to be clear.
= =C2=A0

However, I am unaware of any curve448-sha512 implementations at
present and would like consensus that it should also follow the mpint
method rather than the RFC 7748 method.

I tend to think the 7748 method, but all the options are pretty terrible h= ere

-Ekr
=C2=A0

Please reply to curdle@ietf.org with= your opinions.

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


--94eb2c07e820abd3f4054f2ddcac-- From nobody Wed May 10 09:57: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 9653012E039 for ; Wed, 10 May 2017 09:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQYVeb2_fCt5 for ; Wed, 10 May 2017 09:57:35 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0109.outbound.protection.outlook.com [104.47.37.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1BD12949B for ; Wed, 10 May 2017 09:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HMdb4XeNk35iGPeZ+lwZnRJbAqcSMSaLcbrzDC2Mg58=; b=iudELkJCM01AI157JUSUpMSbR3UpqYC8UG6RJVzOO9iG9rzzsBXa+Y2FIHkntc0+jS6warj1I5baJD06v9l0WsPOlnTqM/bW7xq/cRn1uZoQXIUWMcKEFUytIX2FMmmgE5tdYuv2e4ZAFmzWpbuXN3G3vq/BE9rnEzPaQY73BT4= Received: from BY1PR0501CA0032.namprd05.prod.outlook.com (10.162.139.42) by MWHPR05MB2911.namprd05.prod.outlook.com (10.168.245.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 16:57:33 +0000 Received: from DM3NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by BY1PR0501CA0032.outlook.office365.com (2a01:111:e400:4821::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5 via Frontend Transport; Wed, 10 May 2017 16:57:33 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT034.mail.protection.outlook.com (10.152.98.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Wed, 10 May 2017 16:57:32 +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; Wed, 10 May 2017 09:57:26 -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 v4AGvQJM029327; Wed, 10 May 2017 09:57: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 2E0EF11513; Wed, 10 May 2017 09:57:26 -0700 (PDT) To: Eric Rescorla CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" In-Reply-To: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Comments: In-reply-to: Eric Rescorla message dated "Wed, 10 May 2017 09:20:37 -0700." From: "Mark D. Baushke" Date: Wed, 10 May 2017 09:57:26 -0700 Message-ID: <46168.1494435446@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39840400002)(39860400002)(2980300002)(199003)(189002)(377454003)(24454002)(9170700003)(2810700001)(229853002)(81166006)(8676002)(7126002)(7696004)(53546009)(77096006)(86362001)(2906002)(5003940100001)(8936002)(5660300001)(7846003)(6916009)(2950100002)(50986999)(345774005)(189998001)(48376002)(50466002)(53936002)(53416004)(55016002)(105596002)(356003)(478600001)(117636001)(76506005)(47776003)(6306002)(6266002)(54356999)(54906002)(4326008)(110136004)(38730400002)(106466001)(305945005)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2911; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT034; 1:fLc6js7/Z9FzTN68CzzD8Oz5PemvvkZ6rsvbqckoYcaRGiGGO3GDT/rwEm4aDjatzM6mrxOPF262ftB6nixmdEVVSgf76tYdQx1XoBxlk6uuRnlhqp3wjojiqRtqZCz36Vk8zTCcG7rV3vitsonn6aupg4aAyUGGxb5A8KcCL4/wEe0rXkE47UnnVKktnG4x61eqypSCqt8A6rIPyvxMQBRy6HjhxELV3nQpnHldXmjHwRTykvVIJK+H/VjkMvLIehhGfplDgy0Ky8vdsS0VlFoakOVGHQAAfGLmx4EirMYljDzd5fLgF5p9DGZluHG5tKNBCrkdLXzrPIV19y2YigSu+uK8Kc9zik9oYtZxSG4NyBLsMkoLOSl0QV3TCM+MioiYovRFyNuDq1RoEIxGUUdVZ3zpRTbMFQXHyOwaY5u0LKvvf7F5Ck1g4vpINE1oAKl3XFx1pD1hhGl/x9pYwBs5HtmtCSBtPwg3nbnLbmD7VxzIHQSMOZaSyvjP459kHinL/dMHXI6VhAVFwHLj5EwSYoZPWn7RDBWBFpV+/gcud71UoyTzB2yU93fnVLkRnvNtYyBW1zsoZLFygXW0BYyh5j2kR0L93Mzlqd9VSj0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a4e02a59-14ac-4df3-fcba-08d497c5a6fa X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR05MB2911; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2911; 3:Zrm7UG1Vdp/e3kSzOXPYecddbl6pWk5G2XCYNOqdFnxQINFw5EQK2Dt01OgPi3Dvfn0es6jy5LyHpMS0nAH1+FH0Is2R5vJt8L4hkMm676gXdhjXGHGzqdybG1dN+VQeYJjAcZ5V/apuzmTQh9GfBomiTnzv2zfpOMZP2tx+3JmIFA14Y015P+z11I8eBFMh+hj/UVt9PSPj3EuDniqVoVjrd+L0FtEbDLyJirlCOc/IazIrpGyuWuK7KPyc4KqC6BkW46PT1g7CyDgcsq40ogPRRgCWplh+LrK2ZkxqYh6hZZwa5zFlaPrOeISI0qJCHPImkcWKt8aL92+hw01eUawUqgNNCag+dTMPAdlNznMU4YNGOg1Ktsv7zPP/684K2NVBhbC96RCzLruhqMMw7ID72FTkyeUWEGj8OWc6xBb9iSueoD4HxHVEcHwrG5dcqEF9BBfodVDwRqFbboJyx19VUEDZrzb3Rnz0Td7fBSPQelmWbTyTCNDsbFNSNTve X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2911; 25:x0tfS421EZmzkCCi7SDA57v5BumqTxZ3lzlqo375UF/DoumszhkaSgjzbeE/85PXq5ae3uEK3I7a5P3xZ2TzgoBvr4fUmiAS/yfIyLVbW6uy/M4hEwU6QC00rI2PwCk9Aprc6MvgjnYZsTY84xzBjmgM2bUxdSow9Y+PDyPdcRwWR3yeEOVXhYPsLEdk6O5QTXdHM0zUY5X4KaZUbw1fML7GW/S1OVPBQR5sHBFB9YRMYh8GLBxwc9Wx6ZmnTJf8iULg2U1b4FGM5ipyqKBISkExyVsQjiq8YBMD+iUZx7HMiiA8o7CL2/YDLNSz3VkbVchI13qdaDiA3rijhjbSrWAx4aLTOcSyEKxhfdb8uuPqIY+DMVWH6EocRcEdNPOOePnut3AcVQfDb5Je0/u3jR0x5NGac6B1tvXDcgWld8yiZz/sLhVFGKd7bHwoiew2LqnCyd+TxMs2cag/GxZ9mudo0sAnl7Ytb1zPHkAK3mQ=; 31:9rOzBfe5m89zTnK+wxkagUDH02mvpPMikf233V5Nu2UX23Ue6kqk5tBLWUoQ9v1HjzgXUmaUSDtIe0jkrx/ZCxNS9P6LqNxd+HBtdWiwk7g857ZQsfgybcjk4oyHh/CbV1LamWkpirNkPm8QvoNCl/T5WQHgk6SouTdghphDlDB/QJ7b9SKVyjvhfXdSeeSMOegHEVoH/TvI/H22YqtUxa3fcLBcpgi9MVOy0PDZ2cMHTLn1k1S+x/FRdtueoMT0xla2AEV3aAbCQjEF3n1M2oOk3hafJhzSN7nnKELQVrU= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2911; 20:Yt2128DOb+Vo/NxYujn6RN3A2Qwvdu1ECS83S4YYqEIQueBarOwsAU0Qnmds551fSegVC391aPMVhWzusc7C3bwDVn0DiLXMmsEbMg/xkJ9QsnlU+2hQH8CVX8cw+KJJXr+4ETthVXWWFg4gRPjojfYxQsw/ylZcPhA83EoBwgxHuMQ1IuQYUtFXTDM70EWnUve9cD3tZQ537Kjl3huiYhp7KfPkiMtcN1oE71D/4Ta/V7oal170WjjuwHz9C8+b80GKPXaOCpCRQe+7Zpg/7Kpu230vZVkw623uzMLWuSCY+FrxLst+SHJzxEn+0hqvs0W+4GG96Dqm+OZ6crDRqjXSfitZw6OfGtEdge3nJ5+ZCEisyWqm53v487PVonOOWmdTDbQurL9mqfNUFQQWz4mi4K/t0NFWVIiel/pg4N5NiNVTq78g42YpnF/tHjdfS1SP4XxpuuvPSDj6xUrDOhybBXH8FAreByNMRcjBf72AHGDJxmG1KwFf0d7b3jMI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(13017025)(13015025)(13024025)(8121501046)(13023025)(13018025)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:MWHPR05MB2911; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2911; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2911; 4:zgJd3k+Q4J5fHuG2/p1EKqokrEFqwIxwrJ4Xpvravj?= =?us-ascii?Q?5U70Hpkb90tEkUwPFIJw3ECr/8DKrC+Yht8p4hguScjqopXr1wOpQ4Az5w2u?= =?us-ascii?Q?cvd8jPVc4sq1YzzT3ZFPy/GVSBMdSHx340LGkyM5ZoqALEsc/zXMIPmQ75M3?= =?us-ascii?Q?42Yk2H9xOFvBDEgIVhtGvQzJEE79pEdO5WrGcTgBA5sUfQiUDS1z/w4FRSUe?= =?us-ascii?Q?+Y+pJP75WVWsrZDXnGMcVq3s14tdRBIoXk2xkJPXHH9ReYFzQcQGmHRgjQbZ?= =?us-ascii?Q?ba4TXYryj/Qhu0/rxGHNlfG4wQe+hsSeLQ98H74Kn78vMFlBIL9oPgkqufFz?= =?us-ascii?Q?VNrDzQzmcgyas8AyeajV1abmgCeL9/EWV8P7wxNhnJ3GMGRfDW0bgs7PbmEv?= =?us-ascii?Q?WAZlCy3eCCUaY5BQ3jlpWfguCj0uL5xl12+QCXj9Le4kXXATaDBIQ1aFV2Wd?= =?us-ascii?Q?WY2jLFfiB6kEhPI0cPK08+0Tq4ssAiGHMs+hKo5JSHVp+mZBN55ieTk5F6gw?= =?us-ascii?Q?1OzdlpVPYiSAgHnLz3avVVPUF8uMLPehTrtJxmIEqF53EIejmAmO/kiPG5D3?= =?us-ascii?Q?Kv+s/umYjCYwOrjdd+K+4iuXmJv1GD4beDFZ9bTlGSrdOwO5oxh0rBpeVbG1?= =?us-ascii?Q?pUSRUvuuCmqAKTAILtmH2Cay5l8yVpJ2r9EhMG1PfV2Krs+OSTGQ6SdkbElh?= =?us-ascii?Q?uWW8/jqQ1dZj2jqu77fW1wudtd1goV9JUQ9xmth0xdCcaL2yOVUmYi5XnvuE?= =?us-ascii?Q?Uaajq8QoEFMUXWfJ3ZdztX5YT4jBZ77zABOn9yPLLcyR9R20RY+RmxXvvIcU?= =?us-ascii?Q?/cGaZUjhLKQNOpwOj7wkiTVcOoHD4cJTsueuk1LBImqEFOBwKK0633f93mGp?= =?us-ascii?Q?eXZDfTg2XKa2FJAmF4vqY9EHXTk7b7un6texMV1cHYSsjpuuLNSlLNuowOP3?= =?us-ascii?Q?/yYjpeQPF2FuS9qsU7VeSBVjWTJZEwtzKRSVUM1N2sbdHYcNybDO7jzOzhlJ?= =?us-ascii?Q?M=3D?= X-Forefront-PRVS: 03030B9493 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2911; 23:GTZv/7sjGUWPb+5fw7niVGGO/J9tbwjjktCNBIC9C?= =?us-ascii?Q?0W8j3H6jD8ghf3h+6uINF/w1IHKd2U6IXQ1MqwTANyUTRQm4utXQwyRIeVYP?= =?us-ascii?Q?lUX7APpVNW9lnlVd6tvxZqMdXirjBvzhD5IReIkZfsmUCiyj1T4i+yeCeoUJ?= =?us-ascii?Q?UHmE47mglOFxQLnAFlgQZ7A/MddKOdrpFmZrpwfQthCGO3tdx+ykGAAXA4bI?= =?us-ascii?Q?aW9zmrpdZhCtc675HLJSnNMEJ0TyG/OTATIBi4UvkgAMMGBvqVawT2BnFA2K?= =?us-ascii?Q?eMoAQjGLtEPsN2fOx0sNIbZuIkuCgw/tHypo4NaQqFm1g97Lz9yIl5qGxzPh?= =?us-ascii?Q?fzOWuH2LiCsudUgns0CilGG+jfWjsRj7kpm2aM2hVjcKlqrJ8O2Fhhrc59oC?= =?us-ascii?Q?1czposVUlNcij2JrICwNJVq7nO8FbotRLMPujV8r8MqUIET6pp5a5C6ujN4j?= =?us-ascii?Q?9+EjOCvn5eKykvS+eNuarV8MM4TRJv2QUa2O14qy77sMl5U08SoAfqgk/tYc?= =?us-ascii?Q?5N+jQhZjfprCqSftYQbgPInsbJSQRVQJ+4VESTPIOdnLcFVUztkQoiYb/u81?= =?us-ascii?Q?vY7DdIiMY2/CZg9CJGtugzdem9qCGco4rRmBlByxnUZEQOHOb223ochasDW+?= =?us-ascii?Q?5jkmKDIDwiaDRlk+gHbIfIPMUNMuoo9YzFsEj3ETJH5ts+63KhR857q7D9JQ?= =?us-ascii?Q?Cpbn04lpKmhtRLYEOg3hRRWZQqCNgbwi7fdDv0o8sKc4rj14xJtE4PvG31/5?= =?us-ascii?Q?6UeVJhfsmql2iQd0AqBBWDMZowO/B+z6uvTIyT/NxIEXJeSSy1+K5G+uL+mF?= =?us-ascii?Q?XTBwvpqHdPU/MwZ7BQMQHjYMHMbHx6s1Lg8LGm7f8UqFry3APYRvJBTjIIKa?= =?us-ascii?Q?Gup/hMZG9lM+njMUUTwyt0P4y88OwfxUSDLXWtYt2p+RDr4/+jkowXe6R+NG?= =?us-ascii?Q?lCoN6z9yIypi3pyHy7XdIX+gZlf1ShsrYVRDamj4yLeES0rDL5erHnXCzn1/?= =?us-ascii?Q?D1K63ulKUVqDVDDq8j/le2/2/a+R9xDTrzTKGhYp+PO1ZkkB4g/hjskzjWgK?= =?us-ascii?Q?4BP88EaAhj1bO0/rJqr3RzetSDgK/q6jKkmZ0qzqjB5BgAloD2kfhezUFzec?= =?us-ascii?Q?jJkdjJ2d0cQwAiwyZqAOZiHzouPp6yzgALQHx/+QPe1G1qUoyJ8VtJ+zWYfr?= =?us-ascii?Q?VTty4qi6iwuXEaFZTigVV4U1kuJJIZurVuKCwQtHMnOIuJWM+qKkpRxD3GYb?= =?us-ascii?Q?4mI2JMqR8GGYPiWSTHyoK6ky4Ruul2UJcx8ogGbBsdz7M6Zx+Vm+keBpPsfo?= =?us-ascii?Q?qd7n6VhJeE6OT1gWqMWjcT3OM0DwrHSMD+MMf9XCkYf?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2911; 6:dq+wNX8gyETl/bfbqgkS0k5BxP5k9thPm6MApkngntQUg4/uI39B87Gkj3trCiQAJpTPjw7EZu+i3lD+Iq0M1SZASpbgI3nUgxv+99ffP+/aZ9gUkO1sP9hfI5gOGoZb3TUg+Q/X/cWvER9RjF6v+FJlGpMKPfEs438/xy5ZmxKNS6beDRxplJzsoDIRbyVYltbTF4+gbGyhnNQHZ0jnTCG6zl6ZyBbZZ+vFm3LqmJmiwWk44h1VEtHNiB3n9kA6V1mya0uFbDTTtAlpI37gUA3Wlb9KTBk9+KGqoFPyP0Bt76SFmuFFAUpZjYU64JfHlPz9iYae8agafyav3aiIeFjvVoiuNlvi3UtIc0EpxEL7GmdozX1mNNLI9j32Y+aiv0M0GDBI0LwZ3oDg7wmoAG86j00Cn/yFyXQiyCPjTvdMjtMgRlz7+T56BsQPu/sOSwsfo5lLR7Iw3UeMXXarZMBi7kzLVYRd2sHDIKnpvuQ7iUoQxVZMf62iDywGigtDp9IfH5E9fXt76rStpvGwr47niqDUBwW01o2yYWDz67A=; 5:B/zK53qa5dnjIbMT569poA0CvLHkk5QxZdxfzmezbc9ah6fqTSjtIyVXfvNrBSxWH5fOnERq70rM7QxQrvinYr6UDEcr019ES8T92DHiajyfpauD4r76cgkbPuwRGrGWIf24xxBHsm80W3bkNXOFjA==; 24:gdRC41hFq/SvGRprBDO9mkz1qbqcf22jv3V3WtR5ZUE7F/alQLl+IBotcDHpsmU42mrb086624OkzLjDckYrcZ3LoMpxuTQVf8azpcdVdQQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2911; 7:Fv6XPXdKSwKjeI0fu5Mr1JzviJrEx6giNSafrLuCuNkyxE/Ns2EO2CogcoctVMoGhjcjJFMBEET+FHyTZgE6k30caVZ5zVP2Rmkt0iFvfUcUqYCTRJuNaw4paGvTjWH5VxrPuhQamZffikbf5DvEwFpbly3RKKVxUgq6hVz7wGDsBhKZCW6F4W1w+0zaSvzoeJvOPgTVysXJX2wdaPkZpfufoMoee5KKdk9kN/oGzxHpYqvqdB0jiMql6ebPxpbqYGVwJtr1PQ63Mvn2JKn4OFjhHtU5Uhqa3zBYCnXPAc3y+YCFqhm0QvojfFu2mcHa0WjD2qaIULdiZjN4CG4exA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2017 16:57:32.8537 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2911 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 10 May 2017 16:57:37 -0000 Eric Rescorla writes: > On Wed, May 10, 2017 at 9:18 AM, Mark Baushke wrote: > > > Hi, > > > > Eric Rescorla has brought to my attention that in > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > > currently specifying the SSH encoding of secrets on the wire using the > > mpint process as described in section 5 of [RFC4251] while RFC 7748 > > describes using a little-endian format: > > > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > > > This seems to be what is being implemeneted for > > curve25519-sha256@libssh.org, so I should make > > an explicit note of this in the draft. > > > > Thanks. To be clear, I'm not saying this is the wrong thing in the draft > (though I do think it's kind of an unfortunate outcome). I just think it's > critically important to be clear. Thank you for the clarification. I agree it is unfortunate. > > However, I am unaware of any curve448-sha512 implementations at > > present and would like consensus that it should also follow the mpint > > method rather than the RFC 7748 method. > > > > I tend to think the 7748 method, but all the options are pretty terrible > here I am agnostic on the best way to deal with curve448 for SSH. I agree all options are unlpleasant. RFC 8032 vs implementations for ssh-ed25519 will have the same issue. So, if https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519 is updated to point to RFC 8032, it will likely need to worry about the mpint vs little-endian encoding issue as well. :-( -- Mark From nobody Wed May 10 10:44: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 298E0129C1E for ; Wed, 10 May 2017 10:44:17 -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 pm3kJ6B-xV4k for ; Wed, 10 May 2017 10:44: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 CE9CB126C0F for ; Wed, 10 May 2017 10:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 328BD3004D8 for ; Wed, 10 May 2017 13:44:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WlsriZALd6XT for ; Wed, 10 May 2017 13:44:14 -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 521D03004B6; Wed, 10 May 2017 13:44:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> Date: Wed, 10 May 2017 13:44:13 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] 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: Wed, 10 May 2017 17:44:17 -0000 Jim: > OneAsymmetricKey version numbering - I am looking at putting some = guidance text on this into the document. I will send it out once I am = happy with it. The handling of version numbers in CMS works with the most primitive = ASN.1 tools. I think that approach should be followed here too. Russ= From nobody Wed May 10 12:42: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 9513F128AB0 for ; Wed, 10 May 2017 12:42:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JfCZIbeRsHfn for ; Wed, 10 May 2017 12:42:44 -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 5F5F912EAAE for ; Wed, 10 May 2017 12:42:21 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id c15so31598574ith.0 for ; Wed, 10 May 2017 12:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rtAxVTPRaNit5Q9lSfuJvWmxF1h1M3lLQkrzFBCykJI=; b=pDVDdWKQScoF2Thd6R0GqDOO3DQcAwJnT/cuSxRdvYpKrcwqNY1/N/vJdVAiEpKpTi RDK/NIcwM3ggG8gf9JSB+sypk2l27uf2mLkqphZp50oKgvfrZnYSkuR0h73F43rCmHRJ 7WQerZ6TzdPS1KWYrYLHmb6wDvhEcbkNimp09yPFB/Bgqa3z7xxGJz3XgdELw7/zB3Y6 IlefBG/TomKwkMA3MPSV/SFArxE+GSPPB2pmKpMSEAuSKGd4ZqaDd+uw+cj6QXcCZcnb 96UIjBmNIBd+zjwTLFjmxrjN+3d1irX6WJ7zmKI/00SN/p3gSp6lR85ljdQtGpG7HfTU U/Rw== 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=rtAxVTPRaNit5Q9lSfuJvWmxF1h1M3lLQkrzFBCykJI=; b=p43JFWuwaRKV6ohP9OOstoCA3obHFg71Vk67W23C2CWlWD6icIbx7iftUUukrPefju FT8u7KaXD7m1ySYEmVkx67sVnBAVZmEmO27PxgFrlQne90J55PxaGJJUcRw6HsrzbFWf 3Fb3fm+R7v2/L/qOGFIERZgk/BPdnHi3h7d3W1G0HLhFtRuzM/GKrxFdp94KWXYBF5Jg OD3Q6WIhtzrbiSNFsO1papCQVNvX7sCi0ZPYkrONDnhtcmlUIVl//C9BP9rNPwipZ3zk S5eQ4Y3cR8ALdSZHUPt6Vx8ykW98FnNWBrmSbB05AOZ5v76WgP6jvfQ89xLqEKBhnvS0 7zsw== X-Gm-Message-State: AODbwcBgfli4Q5NjG+cMNguNSPnfyZJVco4/oaEalq6Lqo04wsjfchjf vOxIQ6vcfvbuDGVuvxTuaNWekAtbgNDs X-Received: by 10.36.124.85 with SMTP id a82mr3075906itd.90.1494445340605; Wed, 10 May 2017 12:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Wed, 10 May 2017 12:42:20 -0700 (PDT) From: Brian Smith Date: Wed, 10 May 2017 09:42:20 -1000 Message-ID: To: curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Curdle] Wanted: A valid PKCS#8 file with attributes 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, 10 May 2017 19:42:47 -0000 Hi, I've been creating some test vectors for Ed25519 and X25519 PKCS#8 files, some of which I've already shared on this list. I would like to create some test vectors that include attributes, but I've not seen any. If somebody could share an example of a valid PKCS#8 file with attributes, especially ones that make sense for PKCS#8, that would be very helpful. Thanks, Brian -- https://briansmith.org/ From nobody Wed May 10 13:10: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 4F7F6129C5A for ; Wed, 10 May 2017 13:10:40 -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 OOKhmJS1tFIr for ; Wed, 10 May 2017 13:10:38 -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 69998129649 for ; Wed, 10 May 2017 13:10:38 -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=1494447033; h=from:subject:to:date:message-id; bh=Jbw3CIVpbBrIFsyrTccFJw4Ysc0kmlsbm8h0JaQ7xY4=; b=PRvS0Q0o3kAsWJywbflc7wxJpqlBYx/m7/wcC4su6El1Nhwf/+dQ91E4+rTrl/k5YNulyqcw262 1KxPJIpdCyJG0bDPyDyTJMde/2USuOLQJHgKWwaNSBr9aCpqOYK6FXEu2ZbRPpMe8p58h2Dob/4ro /tOg2bEalOqhBXwJe/hGmbhmQa+SWtH3iBUYf9vsi4Rf9yAbqtw9PDTbUF/S478ujWZtBV8W7x6c1 2p2ID23RRjjgqI5i2fcS71gBUKlQdjFGfZRcxOcqTQQA4cbRJUQUv9mIWGqRTpvzEh1keuIxuuu+J c70B/cW7vGlLWlSSLKMJdDUMYzP93YJCeipw== 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, 10 May 2017 13:10:33 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 13:10:23 -0700 From: Jim Schaad To: CC: 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <13876.1494379636@eng-mail01.juniper.net> <000501d2c988$e6c681f0$b45385d0$@augustcellars.com> <92705.1494427787@eng-mail01.juniper.net> In-Reply-To: <92705.1494427787@eng-mail01.juniper.net> Date: Wed, 10 May 2017 13:10:43 -0700 Message-ID: <004e01d2c9c9$8290e8b0$87b2ba10$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAWt1TpUBWsHjHAN7FOQdAZi7CHQBRXVEwwHSbWjqAhDWZLYBJz7gxAIubzaEoWxuOnA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 20:10:40 -0000 I think what you are looking for is the ASN.1 module which is residing in draft-ietf-curdle-pkix. This is where the assignment is actually being done. The IANA work is really just booking to make sure we don't re-use an OID value. Jim -----Original Message----- From: mdb@juniper.net [mailto:mdb@juniper.net] Sent: Wednesday, May 10, 2017 7:50 AM To: Jim Schaad Cc: Daniel Migault ; Eric Rescorla ; Benjamin Kaduk ; Martin Thomson ; curdle Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt Jim Schaad writes: > I do not believe that this has historically been part of the IANA > mission. How have OID assignments for RFC standards been handled in the past? MIBs do exist under the IANA.org site: https://www.iana.org/assignments/ianacharset-mib/ianacharset-mib I know I have seen MIBs with a copyright of "The Internet Society" in the past as well as the IANAifType-MIB.mib with types that are prefixed with the 'IANA' string and ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" inside of the various MIBs. It seems imprudent for there not to be a machine readable record of the 1.3.101.100 .. 1.3.101.127 OIDs. I sort of expect a section of this draft to have the OID assignments that may be extracted. Something along the lines of RFC 3560 perhaps? id-X25519 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 110 } id-X448 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 111 } id-EdDSA25519 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 112 } id-EdDS448 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 113 } id-EdDSA25519-ph OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 114 } id-EdDS448-ph OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 115 } Safecurves-pkix-0 OBJECT IDENTIFIER ::= { iso(1) dentified-organization(3) thawte(101) 120 } along with all of the other book-keeping needed to deal with the reserved for future sub-registry and unallocated 116 thru 119 and 121 thru 127 values. If this is all wrong, please feel free to suggest the right way to do it. -- Mark From nobody Wed May 10 14:21: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 5636A12EACF for ; Wed, 10 May 2017 14:21:36 -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 LHlEz-M8AZvk for ; Wed, 10 May 2017 14:21:34 -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 95ED6128616 for ; Wed, 10 May 2017 14:21:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C4BB93004DB for ; Wed, 10 May 2017 17:21:33 -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 qvbTuBF0waPp for ; Wed, 10 May 2017 17:21: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 735E13004B6; Wed, 10 May 2017 17:21:32 -0400 (EDT) From: Russ Housley Message-Id: <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_99E8EDA4-9B85-4D7F-ABC6-8F13CF3EEB5F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 17:21:32 -0400 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> Cc: curdle To: Daniel Migault References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:21:36 -0000 --Apple-Mail=_99E8EDA4-9B85-4D7F-ABC6-8F13CF3EEB5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d like to see the CURDLE WG adopt the document. I wonder if this document should really assign 120. My understanding is = that these OIDs are to be used when there is a desire for a short OID. = There is no reason to consume a short OID for an ASN.1 module = identifier; they never get transmitted. I suggest we save 120 for an = OID that will be transmitted. Russ > On May 9, 2017, at 2:35 PM, Daniel Migault = wrote: >=20 > Hi, > =20 > This is a call for adoption of the following draft: = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ = > =20 > If you believe this draft should not be adopted as a WG document = please let us know by May 23. > Please also provide your reviews of the draft.=20 > =20 > Yours,=20 > Daniel=20 >=20 --Apple-Mail=_99E8EDA4-9B85-4D7F-ABC6-8F13CF3EEB5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99d like to see the CURDLE WG adopt the document.

I wonder if this = document should really assign 120.  My understanding is that these = OIDs are to be used when there is a desire for a short OID.  There = is no reason to consume a short OID for an ASN.1 module identifier; they = never get transmitted.  I suggest we save 120 for an OID that will = be transmitted.

Russ


On May 9, 2017, at 2:35 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,
 
This is a call for adoption of the following = draft: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-regist= ry/
 
If you believe this draft should not be adopted as a WG = document please let us know by May 23.
Please also provide your reviews of the = draft. 
 
Yours, 
Daniel 

= --Apple-Mail=_99E8EDA4-9B85-4D7F-ABC6-8F13CF3EEB5F-- From nobody Wed May 10 14:26: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 CB1F412EAD8 for ; Wed, 10 May 2017 14:26:24 -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 WYhNLVonxRLn for ; Wed, 10 May 2017 14:26:23 -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 B96C1128616 for ; Wed, 10 May 2017 14:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 26E0B30050D for ; Wed, 10 May 2017 17:26:23 -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 hZZ9dTU3K4xd for ; Wed, 10 May 2017 17:26:22 -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 F24333004B6; Wed, 10 May 2017 17:26:21 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5B0E6820-6F04-49B1-AD26-457B573EDF9F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 17:26:22 -0400 In-Reply-To: <92705.1494427787@eng-mail01.juniper.net> Cc: curdle To: "Mark D. Baushke" References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <13876.1494379636@eng-mail01.juniper.net> <000501d2c988$e6c681f0$b45385d0$@augustcellars.com> <92705.1494427787@eng-mail01.juniper.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:26:25 -0000 --Apple-Mail=_5B0E6820-6F04-49B1-AD26-457B573EDF9F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mark: >> I do not believe that this has historically been part of the IANA >> mission. > > How have OID assignments for RFC standards been handled in the past? The closest example to this situation lead to the publication of RFC 7107. When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc. Russ --Apple-Mail=_5B0E6820-6F04-49B1-AD26-457B573EDF9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mark:

I do not believe that this = has historically been part of the IANA
mission.

How have OID assignments for RFC = standards been handled in the = past?

The closest example to this situation lead to the publication = of RFC 7107.

   When the S/MIME Mail Security = Working Group was chartered, an object
  =  identifier arc was donated by RSA Data Security for use by = that
   working group.  This = document describes the object identifiers that
 =  were assigned in that donated arc, transfers control of that arc = to
   IANA, and establishes IANA = allocation policies for any future
  =  assignments within that arc.

Russ
= --Apple-Mail=_5B0E6820-6F04-49B1-AD26-457B573EDF9F-- From nobody Wed May 10 15:07: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 D98EF1293E8 for ; Wed, 10 May 2017 15:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QzJQeM5zqV2 for ; Wed, 10 May 2017 15:07:34 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156051292C5 for ; Wed, 10 May 2017 15:07:34 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id b68so4620202ywe.3 for ; Wed, 10 May 2017 15:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ic+ufQODi+fXwusZ+hdUJrLMplGzjd9ZDaelVcjRtn0=; b=s2PXtk947+SLeeR28AmNDajV7AueV7WhJTMDc7voeHGXgb/Cd17/nxFMeGuh/Jlxqo I1/eUbDKhU8udelplOGF4SfoEefNA6zBb/6+PGqInXMNvp2RysP4kr47nzqh6IJMin9m ajcs8d8n3nziTFGVt2hqe6dMnHZ77L9xm+IkARQdbOvkdefD5IZ3op8+bH8MlTK5gf/Q lWDZTINtcXaXQLvuAwrm7/22R0Dkn4QFUpG/hV5frlQzV3/Fdk9HXZeYDBjVv3N451Uo 0dtY/VKL5b9qve2n47LLMh2F+XON5T+I65+CacBoZ01b0pQu+JMdbN4RnViqR2iS5T8U /LBg== 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=ic+ufQODi+fXwusZ+hdUJrLMplGzjd9ZDaelVcjRtn0=; b=lgjNGQ2xch+ovoWmjdpSmpkJjJnFgsz4XVW720UxStf+PvA3VcWBmo6vDt8SqFKAXW K11o2Cdw75pyYhPHKossgy2rVfhxRGxmQjjyIA12qX3XirREStfFELZWkz0egYTluNKO rAbuUmlrykVOGpWvQdPn93YDFZyHSsSnvaWpMak2ISrFlPR6Y1zDMc8J7a2dZi9cpHLr H6NvlVqBx3And2VkCNOQmPg1/oHGP0s9N7jXJRQD3dluc1eRXV0LtytNK1IQqfBXnbPk WEAJtdcJmJEyUxKTngAyRNan1qKxGFoSPhImo944uv/eU7gufbkX0V/05rGQpYgDEhRs kzGg== X-Gm-Message-State: AODbwcBEU52/JBem05YpjzgmPfEo/r3bTanGEpQmkieRdY6N8Y3uzbu8 QC9mQOwtA3vRL7CmiU2rF+MDSVH1F7rjtlw= X-Received: by 10.13.255.199 with SMTP id p190mr6530668ywf.312.1494454053237; Wed, 10 May 2017 15:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 15:06:52 -0700 (PDT) In-Reply-To: <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> From: Eric Rescorla Date: Wed, 10 May 2017 15:06:52 -0700 Message-ID: To: Russ Housley Cc: Jim Schaad , curdle Content-Type: multipart/alternative; boundary=94eb2c087eeafa1fa1054f32b214 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Wed, 10 May 2017 22:07:37 -0000 --94eb2c087eeafa1fa1054f32b214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I apologize but I just took a look at the language around invalid points. I would suggest you use the same language as TLS here: For X25519 and X448, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748]. LMK what you think. Best, -Ekr On Wed, May 10, 2017 at 6:50 AM, Russ Housley wrote: > Yes, that works for me. I=E2=80=99ll post an updated I-D later today. > > Russ > > > On May 9, 2017, at 7:59 PM, Eric Rescorla wrote: > > I guess I would focus on the uniqueness of the input, because the output'= s > uniqueness is largely a function of: > > 1. Input uniqueness > 2. The number of discrete inputs. > > So, I think I would say: > > "it MUST be selected in a manner that ensures it is unique with high > probability" > > -Ekr > > > > On Tue, May 9, 2017 at 3:35 PM, Russ Housley wrote= : > >> >> On May 9, 2017, at 5:16 PM, Eric Rescorla wrote: >> >> >> On Tue, May 9, 2017 at 1:25 PM, Russ Housley >> wrote: >> >>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>> > additional keying material supplied by the sending agent. Note th= at >>> > [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>> > SEQUENCE that includes the ukm field. If the ukm field is present= , >>> > the ukm is placed in the entityUInfo field. The ukm value need no= t >>> > be longer than the key-encryption key that will be produced by the >>> > KDF. >>> > >>> > Need not? Please clarify what the purpose is here. It seems like >>> > it's to generate a unique KEK. In that case, the security bounds >>> > are what, uniqueness? >>> >>> I suggest this wording: >>> >>> =E2=80=A6 There is no security benefit to using a ukm value that is >>> longer than the key-encryption key that will be produced by >>> the KDF. >>> >>> >>> Hmm... I believe that this statement is true, but it also seems to be >>> incomplete. I may be reasoning about this incorrectly, but it seems >>> to me that the minimal security requirement is that the UKM be >>> unique, but that can be achieved with a value much smaller than >>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>> then you would still be OK with a randomly-generated 128-bit >>> UKM. And if we're concerned about random collisions, then the >>> usefulness bound is actually min(|KEK|, |hash compression function >>> size|). >>> >>> >>> Yes. The umm value needs to be different for each invocation of the KDF= , >>> otherwise it does not provide the assurance that different keying mater= ial >>> will be produced. Of course, an implementation will generate the umm v= alue >>> using random number generator, not track the values that are used. Sev= eral >>> years ago, there was a discussion about the size of the ukm needed. So= me >>> people were suggesting crazy large values, and the point was made that >>> anything beyond the SIZEOF(KEK) did not improve security. >>> >>> Are you asking for a sentence saying that the ukm, if present, MUST be >>> at least 128 bits? >>> >>> [JLS] I would disagree that the value has to be random, a counter will >>> work as well. (An encrypted counter is better.) I not be happy with a >>> fixed size requirement on this easier. There is no reason to make such= a >>> requirement that I can think of. A 64-bit counter is just as rational.= It >>> might make more sense to change this statement into something along the >>> lines of >>> >>> * Any pair of static keys MUST NOT be used more times than the size of >>> the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limit= on >>> the number of times the key pair can be used. >>> * The size of the KEK is normally not longer than the length of the >>> resulting KEK as that is the limit of unique values that can be generat= ed >>> in any event. >>> >>> >>> Section 2 already says that the ephemeral key MUST be used for only one >>> message. Thus, a UKM is not really needed. However, the CMS requires >>> support for a UKM if the sender include it. For this reason, the docum= ent >>> says how to handle it in the KDF if it is present. >>> >>> You are correct that a counter, encrypted counter, or random value will >>> work, even if the originator uses the same ephemeral key for many >>> messages. The text does not limit the choices in any way. >>> >>> The text already says that there is no security reason for a UKM value >>> that is longer than the KEK. I think that EKR is asking for guidance o= n >>> the minimum size too. >>> >>> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size w= ould be >>> one bit. Although this is not legal from an ASN.1 standpoint =E2=80=93= so the >>> minimum would be one byte. >>> >>> A single byte with all bits zero and two bytes with all bits zero are >>> different ukm values because of the way that they are used in the >>> ECC-CMS-SharedInfo structure. Note that this would not be the case if = the >>> ukm value was only used as a salt value to HKDF. I do not see any reas= on >>> to specify a minimum length of this value. The only thing that is requ= ired >>> is uniqueness, EKR is correct about saying this. >>> >>> >>> I suggest: >>> >>> The ECC-CMS-SharedInfo entityUInfo field optionally contains >>> additional keying material supplied by the sending agent. Note that >>> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>> SEQUENCE that includes the ukm field. If the ukm field is present, >>> the ukm is placed in the entityUInfo field. When present, the ukm >>> ensures that a different key-encryption key is generated, even when >>> the originator ephemeral private key is improperly used more than >>> once. Therefore, if the ukm field is present, it MUST be selected i= n >>> a manner that ensures a unique KDF output; >>> >> >> Is this actually possible? The KDF is basically a PRF, so there is some >> chance that 0*128 and 1*128 produce the same output. >> >> >> s/ensure/will with very high probability produce/ >> >> Russ >> >> >> > > --94eb2c087eeafa1fa1054f32b214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I apologize but I just took a look at the language around = invalid points. I would suggest
you use the same language as TLS here:<= /div>

=C2=A0 =C2=A0For X25519 and X448, implementat= ions SHOULD use the approach
=C2=A0 =C2=A0specified in [RFC7748] = to calculate the Diffie-Hellman shared secret.
=C2=A0 =C2=A0Imple= mentations MUST check whether the computed Diffie-Hellman shared
= =C2=A0 =C2=A0secret is the all-zero value and abort if so, as described in<= /div>
=C2=A0 =C2=A0Section 6 of [RFC7748].=C2=A0 If implementers use an= alternative
=C2=A0 =C2=A0implementation of these elliptic curves= , they SHOULD perform the
=C2=A0 =C2=A0additional checks specifie= d in Section 7 of [RFC7748].

LMK what you th= ink.

Best,
-Ekr


On Wed, May 10,= 2017 at 6:50 AM, Russ Housley <housley@vigilsec.com> wro= te:
Y= es, that works for me.=C2=A0 I=E2=80=99ll post an updated I-D later today.<= span class=3D"HOEnZb">

Russ


On May 9, 2017, at 7:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I guess I would focus on the uniqueness of the input, because the= output's uniqueness is largely a function of:

1. In= put uniqueness
2. The number of discrete inputs.

So, I think I would say:

"it MUST be selected in=C2=A0a manner that ensures it is unique with high probability&qu= ot;

-Ekr



On Tue, May 9, 2017 at 3:35 PM, Russ Hou= sley <housley@vigilsec.com> wrote:

On May 9, 2017, = at 5:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, May 9, 2017 at 1= :25 PM, Russ Housley <housley@vigilsec.com> wrote:
<= div class=3D"m_3772264264542195108m_-3948390049094588018h5">
>=C2=A0 =C2=A0 The ECC-CMS-SharedInfo entityUInfo field opt= ionally contains
>=C2=A0 =C2=A0 additional keying material supplied b= y the sending agent.=C2=A0 Note that
>=C2=A0 =C2=A0 [CMS] requires im= plementations to accept a KeyAgreeRecipientInfo
>=C2=A0 =C2=A0 SEQUEN= CE that includes the ukm field.=C2=A0 If the ukm field is present,
>= =C2=A0 =C2=A0 the ukm is placed in the entityUInfo field.=C2=A0 The ukm val= ue need not
>=C2=A0 =C2=A0 be longer than the key-encryption key that= will be produced by the
>=C2=A0 =C2=A0 KDF.
>
> Need not= ? Please clarify what the purpose is here. It seems like
> it's t= o generate a unique KEK. In that case, the security bounds
> are what= , uniqueness?

I suggest this wording:

=C2=A0 =C2=A0=E2=80=A6 = There is no security benefit to using a ukm value that is
=C2=A0 =C2=A0l= onger than the key-encryption key that will be produced by
=C2=A0 =C2=A0= the KDF.
=C2=A0
Hmm... I believe that thi= s statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly,= but it seems
to me that= the minimal security requirement is that the UKM be
unique, but that can be achieved with a value = much smaller than
the KE= K. For instance, it seems like if you have a 256-bit KEK,
then you would still be OK with a randoml= y-generated 128-bit
UKM.= And if we're concerned about random collisions, then the=
usefulness bound is actually min(|KEK= |, |hash compression function size|).
=
=C2=A0
Yes. The umm value needs to be different for each in= vocation of the KDF, otherwise it does not provide the assurance that diffe= rent keying material will be produced.=C2=A0 Of course, an implementation w= ill generate the umm value using random number generator, not track the val= ues that are used.=C2=A0 Several years ago, there was a discussion about th= e size of the ukm needed.=C2=A0 Some people were suggesting crazy large val= ues, and the point was made that anything beyond the SIZEOF(KEK) did not im= prove security.
=C2=A0
Are you asking for a sent= ence saying that the ukm, if present, MUST be at least 128 bits?<= /u>
=C2=A0
[JLS] I would = disagree that the value has to be random, a counter will work as well.=C2= =A0 (An encrypted counter is better.)=C2=A0 I not be happy with a fixed siz= e requirement on this easier.=C2=A0 There is no reason to make such a requi= rement that I can think of.=C2=A0 A 64-bit counter is just as rational.=C2= =A0 It might make more sense to change this statement into something along = the lines of=C2=A0<= /div>
=C2=A0
* Any pair of static keys MUST NOT be used more times than the size of = the key.=C2=A0 I.e. if 128-bit KEKs may be used, then there is a 2^128 limi= t on the number of times the key pair can be used.
* The size of t= he KEK is normally not longer than the length of the resulting KEK as that = is the limit of unique values that can be generated in any event.=
=C2= =A0
Section 2 already says that the ephemeral k= ey MUST be used for only one message.=C2=A0 Thus, a UKM is not really neede= d.=C2=A0 However, the CMS requires support for a UKM if the sender include = it.=C2=A0 For this reason, the document says how to handle it in the KDF if= it is present.
=C2=A0
You are correct that a counter, encrypted count= er, or random value will work, even if the originator uses the same ephemer= al key for many messages.=C2=A0 The text does not limit the choices in any = way.
=C2=A0
The text already says that there is no security reason for= a UKM value that is longer than the KEK.=C2=A0 I think that EKR is asking = for guidance on the minimum size too.
= =C2=A0
[JLS] It= =E2=80=99s kind of a stupid thing to do, but the minimum size would be one = bit.=C2=A0 Although this is not legal from an ASN.1 standpoint =E2=80=93 so= the minimum would be one byte.=C2=A0=
<= /u>=C2=A0
A single byte with all bits zero and two bytes with all bits zero are diff= erent ukm values because of the way that they are used in the ECC-CMS-Share= dInfo structure.=C2=A0 Note that this would not be the case if the ukm valu= e was only used as a salt value to HKDF.=C2=A0 I do not see any reason to s= pecify a minimum length of this value.=C2=A0 The only thing that is require= d is uniqueness, EKR is correct about saying this.=C2=A0

=
I suggest:

=C2=A0 =C2=A0The= ECC-CMS-SharedInfo entityUInfo field optionally contains
=C2=A0 = =C2=A0additional keying material supplied by the sending agent.=C2=A0 Note = that
=C2=A0 =C2=A0[CMS] requires implementations to accept a KeyA= greeRecipientInfo
=C2=A0 =C2=A0SEQUENCE that includes the ukm fie= ld.=C2=A0 If the ukm field is present,
=C2=A0 =C2=A0the uk= m is placed in the entityUInfo field.=C2=A0 When present, the ukm
=C2=A0 =C2=A0ensures that a different key-encryption key is generated, eve= n when
=C2=A0 =C2=A0the originator ephemeral private key is impro= perly used more than
=C2=A0 =C2=A0once.=C2=A0 Therefore, if the u= km field is present, it MUST be selected in
=C2=A0 =C2=A0a manner= that ensures a unique KDF output;

<= /div>
Is this actually possible? The KDF is basically a PRF, so there i= s some
chance that 0*128 and 1*128 produce the same output.
=

s/ensure/wi= ll with very high probability produce/

Russ



--94eb2c087eeafa1fa1054f32b214-- From nobody Wed May 10 15:17: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 AFD28129A99 for ; Wed, 10 May 2017 15:17:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ciiw7l6NWW0U for ; Wed, 10 May 2017 15:17:33 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 D00E9129AA0 for ; Wed, 10 May 2017 15:17:32 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f102so10732773ioi.2 for ; Wed, 10 May 2017 15:17:32 -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:content-transfer-encoding; bh=ncMZqUN1+zwPtS6aEnZFchuBvlt5BSpwS8sHk4q1yF8=; b=w7k/sz79DNSinSn4XzUN14+P6Ows8z+yPQybIHGYXEl0l2jzuM6imZMQX0OA7laVop zN6IVB7kLJF8Do34zTLuLZLB++KhpfJxP8XWb4/h+3a2OD+cy50KF31w4m89qIxSxsmr DSogNJb/oMM7pF/YLzqYq/PdoYVczbjh5QVI3/7wFktek5fuXRakS6X/Mcf8QjGjtMjn 7qqiZT2syRKn7Khsv4rTl5lDlAdobjCeZ9DWp/Hsmn9X4amfius+8BESln8DNNSZ98D1 xeQ2azKONBcbtLiy3milkmTWaneTU4c96IuXDEr1WazJKsB0p3EV35LidzTr5SawQPTC Vo8Q== 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:content-transfer-encoding; bh=ncMZqUN1+zwPtS6aEnZFchuBvlt5BSpwS8sHk4q1yF8=; b=QlQRu7Hvq2SHccVpO2NgVI2b1reI5fIDz4P4HKFVjGl3EAusKmBTq96oysQP5GL2Rq L7ujCNK17pxHR/LCUmdeloaxaJIzwV+XlOO3+XN4hL6x3MR+We0+BssqWQ4msoRudR0l w93CrIfIYVU+hW1kmO4z657WepNqsxaHyjt6fLQ4JuTJ1XI2PRFLps3q2uqSAwEfGfej n+F1Kd6fv4XYq+bISFsi/FYTW4wAtc2fvkuzq+mXy5LnhPE8XMZ7C80xoDfRxGwcS3im SgQc4FOkhZa0aOebbikLsOq8CTPlyLAwUPA3rzGiGT5jZDxJ09GUFkwFErWc9qIeCLvX PIZQ== X-Gm-Message-State: AODbwcBmnUX71U0IJKIrnAXI2d+XqRERRpFFPOz6AJi8p+DXZaexuYFj T+J//JOmVaF/q6q2zLNIpMNTBbLX135o X-Received: by 10.107.52.79 with SMTP id b76mr5762740ioa.150.1494454651812; Wed, 10 May 2017 15:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Wed, 10 May 2017 15:17:31 -0700 (PDT) In-Reply-To: <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> From: Brian Smith Date: Wed, 10 May 2017 12:17:31 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 10 May 2017 22:17:37 -0000 Here are some test vectors for X25519 private key bit masking, where each vector is a valid PKCS#8 v2 file. These tests every combination of high and low bits for an all-ones private key. The masked private key is the same for each case and thus the public key is the same for each case. Please incorporate all these into the RFC as test vectors, in addition to all the ones I previously posted. Note that the same kind of test cannot be done for Ed25519, because in Ed25519 PKCS#8 files the private key field is the seed that is hashed with SHA-512 to get the actual private key scalar; i.e. for Ed25519 it isn't the PKCS#8 file's privateKey field that gets masked, but rather an intermediate value. X25519 with private key high bits 0b00, low bits 0b000. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b001. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPn///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b010. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPr///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b011. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPv///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b100. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPz///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b101. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP3///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b110. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP7///////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b00, low bits 0b111. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP////////////////////////////////////////8/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b000. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b001. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPn///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b010. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPr///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b011. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPv///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b100. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPz///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b101. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP3///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b110. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP7///////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b01, low bits 0b111. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP////////////////////////////////////////9/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b000. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b001. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPn///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b010. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPr///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b011. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPv///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b100. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPz///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b101. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP3///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b110. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP7///////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b10, low bits 0b111. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP////////////////////////////////////////+/oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b000. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPj/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b001. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPn/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b010. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPr/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b011. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPv/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b100. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIPz/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b101. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP3/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b110. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP7/////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- X25519 with private key high bits 0b11, low bits 0b111. -----BEGIN PRIVATE KEY----- MFMCAQEwBQYDK2VuBCIEIP//////////////////////////////////////////oS MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg=3D=3D -----END PRIVATE KEY----- Cheers, Brian On Wed, May 10, 2017 at 4:21 AM, Jim Schaad wrote: > I have not yet gotten to the point of validating the edge cases, although= the number seems to be getting to the point of a test suite which I would = prefer to handle in a different manner. > > I have been reading the curve drafts and looking at my implementation to = try and figure out what the rules are and what the implications are relativ= e to what is being asked for. > > Public keys - I think that it makes sense to talk about saying that check= s needs to be done on public keys. For the set of checks I can just refere= nce the two drafts, I do not think that I need to re-state them in this dra= ft. > > Private keys - There is a slightly interesting trade-off that may need to= be considered at this point. One can either have the keys in the correct = format, or one can require that the correct masking be applied during the i= mport step. The reason for requiring the latter is that it removes some of= the fixed structure of the private key. This has a (very small) advantage= as a totally random item is harder to make guesses at. It is true however= that there is other structure in the text that is encrypted so this would = be a very small advantage. When I wrote my code, I did the import and then= the masking step as the masking needs to be done in a lot of cases when op= erations are done. Do people have opinions on this? > > OneAsymmetricKey version numbering - I am looking at putting some guidanc= e text on this into the document. I will send it out once I am happy with = it. > > Jim > > > > > -----Original Message----- > From: Brian Smith [mailto:brian@briansmith.org] > Sent: Tuesday, May 9, 2017 6:32 PM > To: Jim Schaad > Cc: curdle > Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-= pkix-04.txt > > Here are some more test vectors for INVALID edge cases of Ed25519 and > X25519 PKCS#8 v2 keys that I would like to have included in the RFC. > > Ed25519 INVALID. The first byte of the public key, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS > IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM > -----END PRIVATE KEY----- > > Ed25519 INVALID. The last byte of the public key, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS > IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk > -----END PRIVATE KEY----- > > Ed25519 INVALID. The first byte of the private key, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VwBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw > MhAGNFfNTf3Q6YpTeWJlgx1GrGpaaF8qVMlpejiyyADWC6 > -----END PRIVATE KEY----- > > Ed25519 INVALID. The last byte of the private key, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VwBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw > MhABrrjj7lulr9kRE0ZtGfTqd/oP7/vYxa3LSZkn8SU193 > -----END PRIVATE KEY----- > > Ed25519 INVALID. The version is v1 but the publicKey field is included. > -----BEGIN PRIVATE KEY----- > MFMCAQAwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw=3D=3D > -----END PRIVATE KEY----- > > Ed25519 INVALID. The version is v2 but the publicKey field is missing. > -----BEGIN PRIVATE KEY----- > MC4CAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA > -----END PRIVATE KEY----- > > Ed25519 INVALID. The publicKey field is indicated with [0] instead of [1]= ; i.e. the attributes are invalid and publicKey is missing. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VwBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC > MDIQAa644+5bpa/ZERNGbRn06nf6D+/72MWty0mZJ/ElNfdw=3D=3D > -----END PRIVATE KEY----- > > X25519 INVALID. The private key's last byte, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VuBCEEH6Iu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJqhIw > MhAOWJcLaHaY9hIDkvGBm2JKcXLJyuxCsL83hbQMYGzChg > -----END PRIVATE KEY----- > > X25519 INVALID. The private key's first byte, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VuBCEEH7GnwgsrTtnHjzaG24L4VHNM3JW+Ud7zBNmODNML9JChIw > MhANTsroYyWV7Klhb92EAP8ungtlqQxS58Bm7mPT7RjB4H > -----END PRIVATE KEY----- > > X25519 INVALID. The public key's first byte, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS > IDIAA7eraRAqyFgDnLBqnjanLu6rRLHvnWHAaB5BRwLf8P > -----END PRIVATE KEY----- > > X25519 INVALID. The public key's last byte, zero, is omitted. > -----BEGIN PRIVATE KEY----- > MFICAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS > IDIACZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCY > -----END PRIVATE KEY----- > > X25519 INVALID. The version is v1 but it has a publicKey field. > -----BEGIN PRIVATE KEY----- > MFMCAQAwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D > -----END PRIVATE KEY----- > > X25519 INVALID. The publicKey field is indicated with [0] instead of [1];= i.e. the attributes are invalid and publicKey is missing. > -----BEGIN PRIVATE KEY----- > MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoC > MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D > -----END PRIVATE KEY----- > > X25519 INVALID. The version is v2 but there is no publicKey field. > -----BEGIN PRIVATE KEY----- > MC4CAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoA > -----END PRIVATE KEY----- > > Cheers, > Brian > > On Sun, May 7, 2017 at 7:39 PM, Brian Smith wrote: >> On Sun, May 7, 2017 at 1:46 PM, Brian Smith wrote= : >>> Here are 5 examples of v2 PKCS#8 Ed25519 private keys, with the >>> public key included, that I'd like to have included in the RFC as >>> test vectors. The first four examples are valid (I hope!) and 5th >>> example is invalid. >> >> Here are 4 pairs of example X25519 PKCS#8 v2 keys. The first key in >> each pair has its public key's high bit clear. The second key in each >> pair is the same except it has its public key's high bit set. >> >> The private key ends with a zero byte. The public key's high bit is >> zero. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS >> MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswoYA=3D=3D >> -----END PRIVATE KEY----- >> >> The private key is the same as the previous one. The public key is >> also the same except its high bit is one. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIKIu/bcT8OFgDSpc6UjjIco6GBN8R/FQkaEscSbBdJoAoS >> MDIQDliXC2h2mPYSA5LxgZtiSnFyycrsQrC/N4W0DGBswo4A=3D=3D >> -----END PRIVATE KEY----- >> >> The private key starts with a zero byte. The public key's high bit is >> zero. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS >> MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0YweBw=3D=3D >> -----END PRIVATE KEY----- >> >> The private key is the same as the previous one. The public key is >> also the same except its high bit is one. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIACxp8ILK07Zx482htuC+FRzTNyVvlHe8wTZjgzTC/SQoS >> MDIQDU7K6GMlleypYW/dhAD/Lp4LZakMUufAZu5j0+0Ywehw=3D=3D >> -----END PRIVATE KEY----- >> >> The public key starts with a zero byte. The public key's high bit is >> zero. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS >> MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/Dw=3D=3D >> -----END PRIVATE KEY----- >> >> The private key is the same as the previous one. The public key is >> also the same except its high bit is one. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEILk6+PsBTElrUDbktWya6voRhmEjk7/6kA3NocUxR5yAoS >> MDIQAAO3q2kQKshYA5ywap42py7uq0Sx751hwGgeQUcC3/jw=3D=3D >> -----END PRIVATE KEY----- >> >> The public key ends with a zero byte, and thus its high bit is zero. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS >> MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYAA=3D=3D >> -----END PRIVATE KEY----- >> >> The private key is the same as the previous one. The public key is >> also the same except its high bit is one. >> -----BEGIN PRIVATE KEY----- >> MFMCAQEwBQYDK2VuBCIEIHLXzckbjCm4crsB85VeSSH7kxonnTnUMO+QfBbe2JVIoS >> MDIQCZxD/fCNjPVwXxYAKr8DhD7Vw0q8PrhpvXW5j2krCYgA=3D=3D >> -----END PRIVATE KEY----- >> >> Cheers, >> Brian >> -- >> https://briansmith.org/ > > > > -- > https://briansmith.org/ > --=20 https://briansmith.org/ From nobody Wed May 10 15:23:35 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5477129ABE for ; Wed, 10 May 2017 15:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nZr5uan2F1gC for ; Wed, 10 May 2017 15:23:28 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 B05DF129A99 for ; Wed, 10 May 2017 15:23:13 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o12so10840750iod.3 for ; Wed, 10 May 2017 15:23:13 -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:content-transfer-encoding; bh=+HUpXL2V/z0z7dT1rYPifTtDXp2W3JdnNfWkeCawVY4=; b=iMtb320fAke/EbHsr5tbodQ2OaCpsepAGRce2aKzyEC/llq6IWLnuF0HCHdDrTcbK1 bXxjtev+WkqQ2HZ/jQVdQEaKaPnqrfSzzvsC0H4v33zLzxvNUD+P4wAey5dvyL67sem7 9Wv+UsZ29u/AOUgxbcgNcRbqopahO2ueKSMDz+zZcptQoo/li215+1TteVIduRPjSZ4x XjpHpfZ46XGGKL75NW8fXT4la4I9Tt1PD44jlKlV5tDeTTElEu6r6i4dGqnDLgG8u5MV nc6uBdEW7GOJovUhz0W1pwdV3oAimczkxsV1SPzl2+ShdTENP/FPWv6sueaQAh26Rb3a 5qnQ== 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:content-transfer-encoding; bh=+HUpXL2V/z0z7dT1rYPifTtDXp2W3JdnNfWkeCawVY4=; b=HoUARYOkbeAmfLExodHjc/BAjBvQdkWh4Xzl4QJPAgY+XYKEYyI6yCp25XxkRMuwZi yvQsCWLY0wGJqzbeIqaFnFMDhkWWpPFvYO3Kif0iCFtgLtyqFSAvwPLdPC6YI4rtcO17 cKM0LpGhnPYNRRFJm/gb/90Q7vW9sAf+LV9rS4ZKSFiWtsV1PHA00ekhPyMJ+1zDqbMD itiln4PUaPhKGq9zai9hQrD+H6od31GDz+Sg9IlaEWosDG8LL4ggoZQohihi7q03waBR xS8Bru6khAyO7qIO6U4qNdE3LnsmMpH8Gl02B2hVZ6bfRx2GLEDgb00dNVUvBKTPe+as xeDA== X-Gm-Message-State: AODbwcBWeds3a2wQIlDCiY0cvL/jzxx/1YaFckLOAK9EZm2fiMTwGf7W bGLcK9yiOXfJ6+AlrOa+RHosi3/Ovg== X-Received: by 10.107.50.136 with SMTP id y130mr6652429ioy.152.1494454993025; Wed, 10 May 2017 15:23:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Wed, 10 May 2017 15:23:12 -0700 (PDT) In-Reply-To: <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> From: Brian Smith Date: Wed, 10 May 2017 12:23:12 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 10 May 2017 22:23:33 -0000 Jim Schaad wrote: > I have not yet gotten to the point of validating the edge cases, although= the number seems to be getting to the point of a test suite which I would = prefer to handle in a different manner. I would prefer the test suite to be incorporated into the RFC, and for it to be considered normative. > Public keys - I think that it makes sense to talk about saying that check= s needs to be done on public keys. For the set of checks I can just refere= nce the two drafts, I do not think that I need to re-state them in this dra= ft. It would be good to see the text that will be used. I personally agree that consistency of the private and public key MUST/SHOULD be checked, but others may disagree. More importantly, there should be a requirement that the v2 form (with the public key) must be accepted. > Private keys - There is a slightly interesting trade-off that may need to= be considered at this point. One can either have the keys in the correct = format, or one can require that the correct masking be applied during the i= mport step. The reason for requiring the latter is that it removes some of= the fixed structure of the private key. This has a (very small) advantage= as a totally random item is harder to make guesses at. It is true however= that there is other structure in the text that is encrypted so this would = be a very small advantage. When I wrote my code, I did the import and then= the masking step as the masking needs to be done in a lot of cases when op= erations are done. Do people have opinions on this? Every possible 32-byte private key should be accepted, and the implementation should mask the input after parsing the privateKey value and before doing the pairwise consistency check (if any) and before doing any operation using the private key. See my other reply where I provide test vectors for this. Cheers, Brian -- https://briansmith.org/ From nobody Wed May 10 15:47: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 30B96128B51 for ; Wed, 10 May 2017 15:47:55 -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 LYcBzLDEAI3R for ; Wed, 10 May 2017 15:47:51 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD981270FC for ; Wed, 10 May 2017 15:47:50 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 64so4660510pgb.3 for ; Wed, 10 May 2017 15:47:50 -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=/49lU8BjAcP5YwmJWlVFiInTngigFd4lvl9wM7yyDso=; b=kGqQjTU0QP5GIxjPXY8KpjMTAf5TnYrjN5zS2nMdvIrGIGeWjfWPruUkjK+K+IQVVE OX717aOaL0MTtbzYwk+ilM8rnKQ3zYLKSxdVBNkqmJGXDu8QL9abViHhnpjjr/7Q4EGR apchmwhSMCodRLjfDAYx/NmVmRhoKI/QZu8dE= 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=/49lU8BjAcP5YwmJWlVFiInTngigFd4lvl9wM7yyDso=; b=rbNs9W5g4hH4/F+Goa3k+gPDlyBrraONoE7TA95OyEDG+Us+MvG+8mez7mMwKIySxk lK6PtQUAH9XvrEwmEVq10ri9z65BLTYxYvn4WQdN+scO8Ke4FtLNOkk/C8+mk3xlk6Ko JdJRWagtoD443ocih3w5zyZ/VktDMgs+IPpNYm7NCpbqjoKz+mgSyj7nLM7pXrOxxm4j bSu+/SZG3qX/FNNH/E7GBg0rhmrlMqs5VtOVc8DNv2TtzHqzI0DL94czphF9v7WUCnQU NYtOC4YQgczaSSdwu1aJSfP5c+XM5p6PZ1yUd9On+AjuPALn6YFkvMX78oB3twqG9KHU 1smQ== X-Gm-Message-State: AODbwcBUJHdUrokrVRuJOulqW/PATZ6YnoM1xL7tGt8EDloEPCrdbP5Y Q0/cJaBPjKzXkBX+68LFJ9IYOEGOJyS4 X-Received: by 10.99.154.18 with SMTP id o18mr8892197pge.59.1494456470340; Wed, 10 May 2017 15:47:50 -0700 (PDT) MIME-Version: 1.0 References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> In-Reply-To: From: David Benjamin Date: Wed, 10 May 2017 22:47:38 +0000 Message-ID: To: Brian Smith , Jim Schaad Cc: curdle Content-Type: multipart/alternative; boundary=f403045e2c0a0c7db7054f334348 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: Wed, 10 May 2017 22:47:55 -0000 --f403045e2c0a0c7db7054f334348 Content-Type: text/plain; charset=UTF-8 On Wed, May 10, 2017 at 6:23 PM Brian Smith wrote: > Jim Schaad wrote: > > I have not yet gotten to the point of validating the edge cases, > although the number seems to be getting to the point of a test suite which > I would prefer to handle in a different manner. > > I would prefer the test suite to be incorporated into the RFC, and for > it to be considered normative. > > > Public keys - I think that it makes sense to talk about saying that > checks needs to be done on public keys. For the set of checks I can just > reference the two drafts, I do not think that I need to re-state them in > this draft. > > It would be good to see the text that will be used. I personally agree > that consistency of the private and public key MUST/SHOULD be checked, > but others may disagree. > > More importantly, there should be a requirement that the v2 form (with > the public key) must be accepted. > I think requiring the consistency check here is excessive. You're now requiring everyone compute it, which means there was no point in including it to begin with. Yes, it provides a corruption check, but a rather convoluted one, as this thread demonstrates. You've got problems with high bits being set, etc. I think folks who care about detecting corruption should add an external checksum to wherever they're getting their keys from. That is simpler, works uniformly for all key types, and avoids raising questions like "why aren't you doing a consistency check on the attributes?". If an application needs both corruption detection *and* is incapable of adding it to the layer above, this is so specific a use case that requiring everyone do it does not make sense. If we really believed this should be universal to private key transport, we would have defined every private key format in the world to be K || hash(K). Instead, I would recommend serving that use case by defining a checksum attribute type in a separate document and getting it standardized. I don't especially object to requiring the v2 form be accepted or fixing BoringSSL to accept it, but if the only use is a mandatory convoluted checksum check, then I would rather we throw v2 away and stick with the simple thing. > > Private keys - There is a slightly interesting trade-off that may need > to be considered at this point. One can either have the keys in the > correct format, or one can require that the correct masking be applied > during the import step. The reason for requiring the latter is that it > removes some of the fixed structure of the private key. This has a (very > small) advantage as a totally random item is harder to make guesses at. It > is true however that there is other structure in the text that is encrypted > so this would be a very small advantage. When I wrote my code, I did the > import and then the masking step as the masking needs to be done in a lot > of cases when operations are done. Do people have opinions on this? > > Every possible 32-byte private key should be accepted, and the > implementation should mask the input after parsing the privateKey > value and before doing the pairwise consistency check (if any) and > before doing any operation using the private key. See my other reply > where I provide test vectors for this. > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045e2c0a0c7db7054f334348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 10= , 2017 at 6:23 PM Brian Smith <brian@briansmith.org> wrote:
Jim Schaad <ietf@augustcellars.com> wrote:
> I have not yet gotten to the point of validating the edge cases, altho= ugh the number seems to be getting to the point of a test suite which I wou= ld prefer to handle in a different manner.

I would prefer the test suite to be incorporated into the RFC, and for
it to be considered normative.

> Public keys - I think that it makes sense to talk about saying that ch= ecks needs to be done on public keys.=C2=A0 For the set of checks I can jus= t reference the two drafts, I do not think that I need to re-state them in = this draft.

It would be good to see the text that will be used. I personally agree
that consistency of the private and public key MUST/SHOULD be checked,
but others may disagree.

More importantly, there should be a requirement that the v2 form (with
the public key) must be accepted.

I think requiring the consiste= ncy check here is excessive. You're now requiring everyone compute it, = which means there was no point in including it to begin with.
Yes, it provides a corruption check, but a rather convoluted on= e, as this thread demonstrates. You've got problems with high bits bein= g set, etc. I think folks who care about detecting corruption should add an= external checksum to wherever they're getting their keys from. That is= simpler, works uniformly for all key types, and avoids raising questions l= ike "why aren't you doing a consistency check on the attributes?&q= uot;.

If an application needs both corruption dete= ction *and* is incapable of adding it to the layer above, this is so specif= ic a use case that requiring everyone do it does not make sense. If we real= ly believed this should be universal to private key transport, we would hav= e defined every private key format in the world to be K || hash(K).

Instead, I would recommend serving that use case by defin= ing a checksum attribute type in a separate document and getting it standar= dized.

I don't especially object to requiring = the v2 form be accepted or fixing BoringSSL to accept it, but if the only u= se is a mandatory convoluted checksum check, then I would rather we throw v= 2 away and stick with the simple thing.
<= div class=3D"gmail_quote">
=C2=A0
> Private keys - There is a slightly interesting trade-off that may need= to be considered at this point.=C2=A0 One can either have the keys in the = correct format, or one can require that the correct masking be applied duri= ng the import step.=C2=A0 The reason for requiring the latter is that it re= moves some of the fixed structure of the private key.=C2=A0 This has a (ver= y small) advantage as a totally random item is harder to make guesses at.= =C2=A0 It is true however that there is other structure in the text that is= encrypted so this would be a very small advantage.=C2=A0 When I wrote my c= ode, I did the import and then the masking step as the masking needs to be = done in a lot of cases when operations are done.=C2=A0 Do people have opini= ons on this?

Every possible 32-byte private key should be accepted, and the
implementation should mask the input after parsing the privateKey
value and before doing the pairwise consistency check (if any) and
before doing any operation using the private key. See my other reply
where I provide test vectors for this.

Cheers,
Brian
--
ht= tps://briansmith.org/

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--f403045e2c0a0c7db7054f334348-- From nobody Wed May 10 15:59: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 3E5981270FC for ; Wed, 10 May 2017 15:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aDRNUBQ0x45G for ; Wed, 10 May 2017 15:59: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 EFB4512009C for ; Wed, 10 May 2017 15:59:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D2C9A6.6EB27930" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494457167; h=from:subject:to:date:message-id; bh=XEgf9bau2voDz41zxePoyYezkL264VWYP0NrJIJRZBA=; b=XORjbUIzoO8n1vpdBgBXo+DNxwcF5IRQ5uZwx8Ti64VI+VPCBbEOav088fAXqnH3IbtLirC6uaB DmoPv3utFUSpyOSvAMn8Rq+p5CX4Txoi7icFikxdShUnSTBytKMa8HrWzuih4LrQWdB2JraffYaet kIok/HR29lcG38EWLSDn968KQzE4DWQ4+12xPMMYvCWcmaKlLlwwszerAJTGMN9aKyigGSuNqfPRe GWfqJmulT4TrBdz/STagW085GvgOEoyw8GE3zS4Jv0rppwp0nsWz4Kpw6ExC5uh5dmXWvJWAcFwd0 uWfGIuL/a/S+r9Z71Sx+kIeojOeL3aMmuS4A== 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, 10 May 2017 15:59:26 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 15:59:17 -0700 From: Jim Schaad To: 'David Benjamin' , 'Brian Smith' CC: 'curdle' References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> In-Reply-To: Date: Wed, 10 May 2017 15:59:37 -0700 Message-ID: <006601d2c9e1$1b1066d0$51313470$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQdwJ1Iy/iAhSOZKsB1zCbUwHBSJH8AuMjGPgCXdDW9gIx5lJ3Ab55p2cBBN3mTwHLTD0/orLlVsA= X-Originating-IP: [24.21.96.37] 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: Wed, 10 May 2017 22:59:35 -0000 ------=_NextPart_000_0067_01D2C9A6.6EB27930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: David Benjamin [mailto:davidben@chromium.org]=20 Sent: Wednesday, May 10, 2017 3:48 PM To: Brian Smith ; Jim Schaad = Cc: curdle Subject: Re: [Curdle] FW: New Version Notification for = draft-ietf-curdle-pkix-04.txt =20 On Wed, May 10, 2017 at 6:23 PM Brian Smith > wrote: Jim Schaad > = wrote: > I have not yet gotten to the point of validating the edge cases, = although the number seems to be getting to the point of a test suite = which I would prefer to handle in a different manner. I would prefer the test suite to be incorporated into the RFC, and for it to be considered normative. > Public keys - I think that it makes sense to talk about saying that = checks needs to be done on public keys. For the set of checks I can = just reference the two drafts, I do not think that I need to re-state = them in this draft. It would be good to see the text that will be used. I personally agree that consistency of the private and public key MUST/SHOULD be checked, but others may disagree. More importantly, there should be a requirement that the v2 form (with the public key) must be accepted. =20 I think requiring the consistency check here is excessive. You're now = requiring everyone compute it, which means there was no point in = including it to begin with. =20 Yes, it provides a corruption check, but a rather convoluted one, as = this thread demonstrates. You've got problems with high bits being set, = etc. I think folks who care about detecting corruption should add an = external checksum to wherever they're getting their keys from. That is = simpler, works uniformly for all key types, and avoids raising questions = like "why aren't you doing a consistency check on the attributes?". =20 If an application needs both corruption detection *and* is incapable of = adding it to the layer above, this is so specific a use case that = requiring everyone do it does not make sense. If we really believed this = should be universal to private key transport, we would have defined = every private key format in the world to be K || hash(K). =20 Instead, I would recommend serving that use case by defining a checksum = attribute type in a separate document and getting it standardized. =20 I don't especially object to requiring the v2 form be accepted or fixing = BoringSSL to accept it, but if the only use is a mandatory convoluted = checksum check, then I would rather we throw v2 away and stick with the = simple thing. =20 =20 [JLS] I was not looking at public keys in the private key blob, but = public keys in the certificate. =20 Jim =20 =20 > Private keys - There is a slightly interesting trade-off that may need = to be considered at this point. One can either have the keys in the = correct format, or one can require that the correct masking be applied = during the import step. The reason for requiring the latter is that it = removes some of the fixed structure of the private key. This has a = (very small) advantage as a totally random item is harder to make = guesses at. It is true however that there is other structure in the = text that is encrypted so this would be a very small advantage. When I = wrote my code, I did the import and then the masking step as the masking = needs to be done in a lot of cases when operations are done. Do people = have opinions on this? Every possible 32-byte private key should be accepted, and the implementation should mask the input after parsing the privateKey value and before doing the pairwise consistency check (if any) and before doing any operation using the private key. See my other reply where I provide test vectors for this. Cheers, Brian -- https://briansmith.org/ _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0067_01D2C9A6.6EB27930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = David Benjamin [mailto:davidben@chromium.org]
Sent: = Wednesday, May 10, 2017 3:48 PM
To: Brian Smith = <brian@briansmith.org>; Jim Schaad = <ietf@augustcellars.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] FW: New Version = Notification for draft-ietf-curdle-pkix-04.txt

 

On Wed, May 10, 2017 at 6:23 PM Brian Smith <brian@briansmith.org> = wrote:

Jim = Schaad <ietf@augustcellars.com> wrote:
> I have = not yet gotten to the point of validating the edge cases, although the = number seems to be getting to the point of a test suite which I would = prefer to handle in a different manner.

I would prefer the test = suite to be incorporated into the RFC, and for
it to be considered = normative.

> Public keys - I think that it makes sense to talk = about saying that checks needs to be done on public keys.  For the = set of checks I can just reference the two drafts, I do not think that I = need to re-state them in this draft.

It would be good to see the = text that will be used. I personally agree
that consistency of the = private and public key MUST/SHOULD be checked,
but others may = disagree.

More importantly, there should be a requirement that = the v2 form (with
the public key) must be = accepted.

 

I think requiring the consistency check here is = excessive. You're now requiring everyone compute it, which means there = was no point in including it to begin with.

 

Yes, it provides a corruption check, but a rather = convoluted one, as this thread demonstrates. You've got problems with = high bits being set, etc. I think folks who care about detecting = corruption should add an external checksum to wherever they're getting = their keys from. That is simpler, works uniformly for all key types, and = avoids raising questions like "why aren't you doing a consistency = check on the attributes?".

 

If an application needs both corruption detection = *and* is incapable of adding it to the layer above, this is so specific = a use case that requiring everyone do it does not make sense. If we = really believed this should be universal to private key transport, we = would have defined every private key format in the world to be K || = hash(K).

 

Instead, I would recommend serving that use case by = defining a checksum attribute type in a separate document and getting it = standardized.

 

I = don't especially object to requiring the v2 form be accepted or fixing = BoringSSL to accept it, but if the only use is a mandatory convoluted = checksum check, then I would rather we throw v2 away and stick with the = simple thing.

 

 

[JLS] I was not looking at public keys in the = private key blob, but public keys in the = certificate.

 

Jim

 

 

> = Private keys - There is a slightly interesting trade-off that may need = to be considered at this point.  One can either have the keys in = the correct format, or one can require that the correct masking be = applied during the import step.  The reason for requiring the = latter is that it removes some of the fixed structure of the private = key.  This has a (very small) advantage as a totally random item is = harder to make guesses at.  It is true however that there is other = structure in the text that is encrypted so this would be a very small = advantage.  When I wrote my code, I did the import and then the = masking step as the masking needs to be done in a lot of cases when = operations are done.  Do people have opinions on this?

Every = possible 32-byte private key should be accepted, and = the
implementation should mask the input after parsing the = privateKey
value and before doing the pairwise consistency check (if = any) and
before doing any operation using the private key. See my = other reply
where I provide test vectors for = this.

Cheers,
Brian
--
https://briansmith.org/

____________________= ___________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

------=_NextPart_000_0067_01D2C9A6.6EB27930-- From nobody Wed May 10 16:02: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 7FD37129B71 for ; Wed, 10 May 2017 16:02:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Abh3HPG0yrhW for ; Wed, 10 May 2017 16:02:17 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 26D1212952E for ; Wed, 10 May 2017 16:02:17 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id k91so11264983ioi.1 for ; Wed, 10 May 2017 16:02:17 -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=MESlc8SERT9uw85z1D4D00pqY5xCs5Q4XOQh6w+DYdk=; b=TwYqSvZowz2EKxadQ01Un2Hna5jaBVYxsct4pRFfpDXTwxxwfA80yNtIB2+g8Dk7Tj Wy+2LjyLje8lpUGhy1kdYdZmxnekM9ZGGK75oHqFeSvKjNO9mV4GNHmNXx+NFYI60LnL StSrYkDWJ1OMvWzbIWRldzxSD+mDo1T/no4Q7/OGVkbNer3KZgEzY78GM/Gg42Ps0Kee QF8cE1E80JhiYM08yotgiC9WBIjw6sVNAWG/Tfl8Y2Glq0QLBwKkOwkqww/jcFd4xMis Qbp7WeXBXRN1wDWVfCBlK7de1Hed0TTu34BOnqHIhOvaTmTnCIGtAVwlTWQ3S3yfXzPy DS3g== 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=MESlc8SERT9uw85z1D4D00pqY5xCs5Q4XOQh6w+DYdk=; b=POP4xUzSfZ2WD4Lf1+1PbChYz9msvrGGlCs7sC+g4B5s8ntIRe2qSJaiXGcgy2/ANj +z4h5QRAmbUMBWW8wv0Z6cAPQE0Y4DP+S/q981wNKn4wdHR+hS+yY+1mNuHf1HVjlqXs vQSwcbl7Jjs9Cl+JhBs/DUnWG7blEJHtoX3DgrhzuVL2IpqwC3mG+qFPwSkouM4HyvRg WG4hr0/QHoY2TMLrk3YerZyQoUCixrOwpkpiN24thWyCQkJ20owIa7tY2TjKxytPQrgZ 3QOqAlcG2dflC1Mtq29DdQ1B1eyKSeFfibsmqi9JKCUZucgpBJ55GCWElDsgjzMF5fzA CY0w== X-Gm-Message-State: AODbwcCvOFcrKWa81Y2hbhw+8/xCRnbfZdbRL4VGdsoI6nylnCw7Oh8I CAuWxz5DxDTHNWN54RhpwIMLsanHCw== X-Received: by 10.107.50.136 with SMTP id y130mr6798863ioy.152.1494457336413; Wed, 10 May 2017 16:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Wed, 10 May 2017 16:02:15 -0700 (PDT) In-Reply-To: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> From: Brian Smith Date: Wed, 10 May 2017 13:02:15 -1000 Message-ID: To: David Benjamin Cc: Jim Schaad , curdle Content-Type: text/plain; charset=UTF-8 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: Wed, 10 May 2017 23:02:18 -0000 David Benjamin wrote: > I don't especially object to requiring the v2 form be accepted or fixing > BoringSSL to accept it, but if the only use is a mandatory convoluted > checksum check, then I would rather we throw v2 away and stick with the > simple thing. Besides being a checksum against corruption, here are the benefits I've found to having the public key in the file: * It protects against the case where the producer of the private key miscalculated the public key (i.e. the producer's math is buggy). * It protects against the case where the consumer of the private key miscalculates the public key (i.e. the consumer's math is buggy). * If you have (a lot of) PKCS#8 documents, you can look up a private key by public key without having to compute the public key from the private key for each one. * If an implementation presents the public key as it is stored in the PKCS#8 file, then the public key will always be present consistently. That is, it provides a way to avoid implementation fingerprinting, although it doesn't mandate implementations try to avoid fingerprinting in this way. Note that RFC 5915 (ECPrivateKey for traditional curves) doesn't require publicKey to be present and it doesn't require the user to check that the private key is consistent with the public key even when it is present. And other standards for those curves also do provide alternatives (see, for example, NIST SP 800-56A section 5.6.3.2). So I agree that saying that the implementation MUST do the check is excessive, but I do think it is a really good idea. Cheers, Brian -- https://briansmith.org/ From nobody Wed May 10 16:03: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 54FFC12952E for ; Wed, 10 May 2017 16:03:30 -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 EgzHJxgaj3Qp for ; Wed, 10 May 2017 16:03:28 -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 A84371293DA for ; Wed, 10 May 2017 16:03:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01D2C9A6.FB5C73E0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494457403; h=from:subject:to:date:message-id; bh=Vsz2fPDMUZImRC/MXfJEW3yAzD63Ke3iUrmaZQqvjhw=; b=e0P/pzKem4bicp+D9aYKaqPhIwFBQKyS9skkebMxdDt3Y4bwWRxxOQY6SlOm8pBr72KC7JRyXNm AkMaDgRkvGdji+yQ9BU6zx3Y/VGD1Qh++HYPBemEbeRkeJ3Gj74e/QxhjSeqVtqydUc2djQd7PdXC 1v24Hq4kbzpAzwqXn8GQ4wDc8keAWDwzAuJXRc4XVBwiX6jQW4OuC2j/n6t+WE4bG4fDHEMpeJ1Sf X/VkZfvtM1GT+Ul1bXc5NMvtw2MQNksdEOANuD7Bq8nKKY896iXxq2RyHhE/+P4pXUXWwKeELInWn ZslvWpqPJY6vc9TYg6lXS8Gd4bOp9wD9ha0g== 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, 10 May 2017 16:03:22 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 16:03:13 -0700 From: Jim Schaad To: 'Russ Housley' , 'Daniel Migault' CC: 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> In-Reply-To: <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> Date: Wed, 10 May 2017 16:03:33 -0700 Message-ID: <006b01d2c9e1$a7b9c540$f72d4fc0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAWt1TpUBWsHjHAN7FOQdAZi7CHQBRXVEwwHSbWjqAmZMeyGhhKBgkA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 23:03:30 -0000 ------=_NextPart_000_006C_01D2C9A6.FB5C73E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I assume that this is really a comment on draft-ietf-curdle-pkix since = that is where the OID is assigned. =20 I have no real problems with doing this if it is general consensus. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, May 10, 2017 2:22 PM To: Daniel Migault Cc: curdle Subject: Re: [Curdle] New Version Notification for = draft-schaad-curdle-oid-registry-00.txt =20 I=E2=80=99d like to see the CURDLE WG adopt the document. =20 I wonder if this document should really assign 120. My understanding is = that these OIDs are to be used when there is a desire for a short OID. = There is no reason to consume a short OID for an ASN.1 module = identifier; they never get transmitted. I suggest we save 120 for an = OID that will be transmitted. =20 Russ =20 =20 On May 9, 2017, at 2:35 PM, Daniel Migault > wrote: =20 Hi, =20 This is a call for adoption of the following draft: = = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ =20 If you believe this draft should not be adopted as a WG document please = let us know by May 23. Please also provide your reviews of the draft.=20 =20 Yours,=20 Daniel=20 =20 ------=_NextPart_000_006C_01D2C9A6.FB5C73E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I assume = that this is really a comment on draft-ietf-curdle-pkix since that is = where the OID is assigned.

 

I have no = real problems with doing this if it is general = consensus.

 

Jim

 

 

From: Curdle = [mailto:curdle-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Wednesday, May 10, 2017 2:22 PM
To: = Daniel Migault <daniel.migault@ericsson.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] New Version = Notification for = draft-schaad-curdle-oid-registry-00.txt

 

I=E2=80=99d = like to see the CURDLE WG adopt the document.

 

I = wonder if this document should really assign 120.  My understanding = is that these OIDs are to be used when there is a desire for a short = OID.  There is no reason to consume a short OID for an ASN.1 module = identifier; they never get transmitted.  I suggest we save 120 for = an OID that will be transmitted.

 

Russ

 

 

On May 9, 2017, at 2:35 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

 

 

If you believe this draft should not be adopted as a WG = document please let us know by May = 23.

Please = also provide your reviews of the draft. 

 

Yours, 
Daniel 

 

=
------=_NextPart_000_006C_01D2C9A6.FB5C73E0-- From nobody Wed May 10 17:52: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 0376B12EAB1 for ; Wed, 10 May 2017 17:52:24 -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 8C6Kffbo0rl3 for ; Wed, 10 May 2017 17:52:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E086012878D for ; Wed, 10 May 2017 17:52:22 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4B0lW6D025058; Thu, 11 May 2017 01:52:18 +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=km1UIMm5ET2SUW0gQY3yH+8DRLWqnHHD64oGda9EOZE=; b=CfTCUI09mEeo6q2Gd7I4koZuABxzpZ6KX62tjeDQxU7di8Wb0arbrcOpBihAqh5Aaooz hVdoZklHkbStuCdIBExhKb/ZOpr0QdiqN6iN9rMR+8g5cOPiUqfK3CaCE/foOFdnQX1l pgdV7dqjtO93gLw8pf+EW52XEFO42dVqr8PsI/H3WFGCjKJzsceyRgBD0O0AxlXj7BVs Wf8qnoANGe1QXLxc7mvNK9vP+Etouj/3hPf/UJi97GGVK7uZRoIq1FMbyXL7fKydTH9v 2ps8nbFe5UFYXAvC13RcgTBcKFybz1ylh5cBdHyoNg6x5h/izxKy4bcBXaJXqzhPn7a7 5w== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2absa169sd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 01:52:18 +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 v4B0pH0p000810; Wed, 10 May 2017 20:52:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a99turg58-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 May 2017 20:52:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 20:52: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.1263.000; Wed, 10 May 2017 20:52:07 -0400 From: "Salz, Rich" To: Russ Housley , Daniel Migault CC: curdle Thread-Topic: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt Thread-Index: AQHSydNq47z6P6VMdkGjQghDF3lU1aHuSQ1w Date: Thu, 11 May 2017 00:52:02 +0000 Message-ID: References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> In-Reply-To: <9FF7BF72-6AFB-41F4-B413-741F4833747C@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.46.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_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-1703280000 definitions=main-1705110005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_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-1703280000 definitions=main-1705110003 Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 00:52:24 -0000 PiBubyByZWFzb24gdG8gY29uc3VtZSBhIHNob3J0IE9JRCBmb3IgYW4gQVNOLjEgbW9kdWxlIGlk ZW50aWZpZXI7IHRoZXkgbmV2ZXIgZ2V0IHRyYW5zbWl0dGVkLiDCoEkgc3VnZ2VzdCB3ZSBzYXZl IDEyMCBmb3IgYW4gT0lEIHRoYXQgd2lsbCBiZSB0cmFuc21pdHRlZC4NCg0KVGhhdCdzIGFuIGV4 Y2VsbGVudCBwb2ludCBhbmQgdGhlIGRyYWZ0IHNob3VsZCByZWZsZWN0IHRoYXQuDQo= From nobody Wed May 10 18:46: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 83C8312EB13 for ; Wed, 10 May 2017 18:46:05 -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 3unvzA6CUL-6 for ; Wed, 10 May 2017 18:46:04 -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 51B1B129488 for ; Wed, 10 May 2017 18:46:04 -0700 (PDT) X-AuditID: c6180641-443ff70000000cb9-18-59137bfdfc76 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5F.C7.03257.DFB73195; Wed, 10 May 2017 22:45:50 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0339.000; Wed, 10 May 2017 21:46:01 -0400 From: Daniel Migault To: "Salz, Rich" , Russ Housley CC: curdle Thread-Topic: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt Thread-Index: AQHSydNo5xLHnrIk0Eue9R1F/QEgUKHukQEA///IoOA= Date: Thu, 11 May 2017 01:46:01 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD941B@eusaamb107.ericsson.se> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> 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.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPoO6/auFIgxuPLC22LpzFbPHqxU12 i/9bOlkcmD0mH1nA7LFkyU8mj1V3vrAGMEdx2aSk5mSWpRbp2yVwZZz/t5CpoI2z4s2bFUwN jC84uhg5OSQETCSOPlvP3sXIxSEkcJRRYt/PvcwQznJGiWPL1rKAVLEJGEm0HepnB7FFBDwk 3p1sZgOxmQVkJNp+fmICsYUFYiQmbFwPVRMrsfHnIjYI20pi4fFjYDaLgKrEp5tfgWwODl4B X4nmZSoQuz6xSCy/0QQ2h1MgWGLD6ddg9YwCYhLfT61hgtglLnHryXwmiKsFJJbsOc8MYYtK vHz8jxXCVpL4+Hs+O8h8ZgFNifW79CFaFSWmdD8EO41XQFDi5MwnLBMYRWchmToLoWMWko5Z SDoWMLKsYuQoLS7IyU03MtzECIyPYxJsjjsY9/Z6HmIU4GBU4uFd8EQoUog1say4MvcQowQH s5II7719wpFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEed+VX4gQEkhPLEnNTk0tSC2CyTJxcEo1 MMqekdtZmGo9b4epXUCgl+X2B77pnt/CJoQdUBYQkjt8eu7/8xYTehfrruv+vKRvb9vh5Ql6 XULNvvNz3jZ2fu+RK3++qP5gov8+q0QRQZfZO8uMa4O/z5D9zXjNe01kuOqhPKnw8zzfyhc3 2d9kWndYdeOGI/s1bq7YxSe2nXHX/EzZzE1mUUosxRmJhlrMRcWJAEfufMSLAgAA Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 01:46:05 -0000 SGksIA0KDQpJIHRob3VnaHQgdGhhdCB0aGUgcGtpeCBkcmFmdCBkaWQgbm90IGNvbnNpZGVyIHBy ZWhhc2ggdmFyaWFudC4gRG8gd2Ugd2FudCB0byBhbGxvY2F0ZSAxMTQgYW5kIDExNSA/IElmIHNv IHdoaWNoIHJlZmVyZW5jZSB3aWxsIHdlIGluZGljYXRlID8gTWF5YmUgYSBjbGFyaWZ5aW5nIG5v dGUgd291bGQgYmUgbmVlZGVkLiANCg0KSW4gYWRkaXRpb24sIHNob3VsZCB3ZSBtYWtlIGV4cGxp Y2l0IHdobyB0byBjb250YWN0IHdoZW4gbmV3IE9JRHMgc2hvdWxkIGJlIGFkZGVkID8NCg0KWW91 cnMsIA0KRGFuaWVsIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2Fseiwg UmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTAs IDIwMTcgODo1MiBQTQ0KVG86IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBE YW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPg0KQ2M6IGN1cmRsZSA8 Y3VyZGxlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDdXJkbGVdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc2NoYWFkLWN1cmRsZS1vaWQtcmVnaXN0cnktMDAudHh0DQoNCj4g bm8gcmVhc29uIHRvIGNvbnN1bWUgYSBzaG9ydCBPSUQgZm9yIGFuIEFTTi4xIG1vZHVsZSBpZGVu dGlmaWVyOyB0aGV5IG5ldmVyIGdldCB0cmFuc21pdHRlZC4gwqBJIHN1Z2dlc3Qgd2Ugc2F2ZSAx MjAgZm9yIGFuIE9JRCB0aGF0IHdpbGwgYmUgdHJhbnNtaXR0ZWQuDQoNClRoYXQncyBhbiBleGNl bGxlbnQgcG9pbnQgYW5kIHRoZSBkcmFmdCBzaG91bGQgcmVmbGVjdCB0aGF0Lg0K From nobody Wed May 10 21:15: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 8741C12EB4B for ; Wed, 10 May 2017 21:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1I4RUcrYRCgL for ; Wed, 10 May 2017 21:15:50 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31F9129A9A for ; Wed, 10 May 2017 21:15:49 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id b68so7176279ywe.3 for ; Wed, 10 May 2017 21:15:49 -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:cc; bh=OAgdgqhzuzocuN3E6FFGutmce5b9fE9ZKgvLWWPF4mo=; b=QmpKzXWISApntxG5UgAHpJZfR6EDBPFKy734q9QjxkYb3vgAeceQSX5G3mHjWNytsS kXBBng2gxX33KV8gbv4C+pvqwUVVn4XkVQ2T3fylpBdgN7C6PzqNje1a8fLH0iesKk/i HGGtiSHocDlwxz5dqVLbYlZJEac2g08ojtAri5LBUwJ0auDv7/jTWHDezvv8S1ivCL+E CQWWy2iknTGkUYKFUvrIoUFJb3uvUDh55uqW4lYIVW41B8ndspjRqMByJ9ma6xLFRiAM 1tbGvA1D3fq43HHbbXoJuEntRhg7GrZMGo87RRrRXSK6nEbf8CzpqVkvC1zmNOQOca1n Hs5g== 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:cc; bh=OAgdgqhzuzocuN3E6FFGutmce5b9fE9ZKgvLWWPF4mo=; b=AvWgPfnOctoW66qtRqSe8HEq+Gx8tzTUISBgju8VcsB+kJk5eQWDI83IpJK90iRoC4 QEXqQ+ZnUD9AkbYfJC1TOhTHLGXdRLC+L9YBdOqq1pJMDxOY6ED0sgg1FmnfQJljyBRc Boq9ZgZERSUAQinu6nISGxxtQvdF567HryOSI6f+bWaaSCjzDRH3xtF209jMH7SV6d4q xq3BkD4L2j5rM+tgWpAHhFALjEv6jeKaAaVv+oPgN6Z/CXL6saT+NLeMUbar4bzX5Y2L ODzpWiSSx6rL/iIbtYUWEq/Lb36RB2C/vGM6Bo6A9X7ousn3RdRhRAI+yDkImQN+H9b1 aa4A== X-Gm-Message-State: AODbwcBQVBgqiNg2Pc4YPSNK9KumTKmcyi8S0T+a1hNmnkxO6k2L2D8g 7PhdgTSRXMN1BeqLEezcr/dg1qd0FbvY X-Received: by 10.129.172.65 with SMTP id z1mr7483930ywj.237.1494476149073; Wed, 10 May 2017 21:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Wed, 10 May 2017 21:15:48 -0700 (PDT) In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: denis bider Date: Wed, 10 May 2017 22:15:48 -0600 Message-ID: Cc: "curdle@ietf.org" Content-Type: multipart/alternative; boundary=f403045ea26efda9d6054f37d739 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 04:15:51 -0000 --f403045ea26efda9d6054f37d739 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Mark! For curve448-sha512, I have no objections for either choice of encoding. What=E2=80=99s more important than the choice of encoding is that there isn= =E2=80=99t doubt about the choice of encoding. I agree it may be slightly preferable to use signed mpint, given that this would be consistent with all other SSH key exchange methods, including Curve25519, and it would be weird for Curve448 to depart from this. denis On Wed, May 10, 2017 at 10:18 AM, Mark Baushke wrote: > Hi, > > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. > > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. > > Please reply to curdle@ietf.org with your opinions. > > Thank you, > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045ea26efda9d6054f37d739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Mark!

For curve448-= sha512, I have no objections for either choice of encoding. What=E2=80=99s = more important than the choice of encoding is that there isn=E2=80=99t doub= t about the choice of encoding.

I agree it may be = slightly preferable to use signed mpint, given that this would be consisten= t with all other SSH key exchange methods, including Curve25519, and it wou= ld be weird for Curve448 to depart from this.

deni= s



On Wed, May 10, 2017 at 10:18 AM, Mark Baus= hke <mdb@juniper.net> wrote:
Hi,

Eric Rescorla <ekr@rtfm.com> has = brought to my attention that in
https://tools.ietf.org/html/draft-ie= tf-curdle-ssh-curves-04 it is
currently specifying the SSH encoding of secrets on the wire using the
mpint process as described in section 5 of [RFC4251] while RFC 7748
describes using a little-endian format:

=C2=A0 GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u,
=C2=A0 in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... = +

This seems to be what is being implemeneted for
curve25519-sha256@libssh.or= g, so I should make
an explicit note of this in the draft.

However, I am unaware of any curve448-sha512 implementations at
present and would like consensus that it should also follow the mpint
method rather than the RFC 7748 method.

Please reply to curdle@ietf.org with= your opinions.

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

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

--f403045ea26efda9d6054f37d739-- From nobody Wed May 10 21:24: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 0CBBF129406 for ; Wed, 10 May 2017 21:24:05 -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 J7QO13gODA86 for ; Wed, 10 May 2017 21:24:04 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99C71294C4 for ; Wed, 10 May 2017 21:24:03 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id o12so14303416iod.3 for ; Wed, 10 May 2017 21:24:03 -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=vizSn0mcEMt/y53Aqr4PmZ44rW1moJmC8obVUzHYF2s=; b=MEkgUEx0e/GjfWmonAjpAN4u6g9SvowNN8nM27GqQ8R+JbbrRoQJym8OIdq5N9i9Zw o0Q39N4jLkmbb80nCEHh4+dTJ7NMm30j84GTyqTYbcHfF265uw9WcDv1kg0UsA5pMhud D26HlgXNV0gGzHsPjLhMHLfDJKy+822F/Fhtw+72hPsHGhWNErxAO5klc8yztbdCjpIl 1I3cxyIp79hLkw48Q7f3kOJbt7xio+o5Io4LxC077OmRugJ4fm6iz9+3NNLLSKF1n7Ma U9dXViKVRKForI1a58nVPrCGaSYH5Stoa9++dIbA3QooykpojmirbkqCSGY9XoB3NIhn gWUw== 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=vizSn0mcEMt/y53Aqr4PmZ44rW1moJmC8obVUzHYF2s=; b=QRA0s2c6c8ootitm1SS+9GTkN7sz/ILPrR3ICS0n6iFxZAgyeB+mNdUKpd/SRS9Kss SPVHWszx9z2sEDR6T+ldUSqKgXvI/E+g58Notc0+1d7I2W2yZt1SehGYYrpVQphU693m W/e9+4LDTTHRSe1JpmBzQ9dVlY0cTKgq/wliA/PvczJ8xR8LY3EciG442DLj3hLk2Ie5 prPlGJrnLJE7T3bBDEAbXrg16qSWETVMIDuUtigfQBzKd9CeKgrvqJ6WGx/yd3CQp/pH 00z0o5OSpnzQm3RBWzrGAVR4yM1fiehpAUHvn+AGGV6d4LROnKKEMi6H5X/R4ei80Gfd 9ztg== X-Gm-Message-State: AODbwcAQ8JFYROVnrOlhAzJUJI+f/4ZHrSJGCyhiL4LtpBrGvf7tJLWa 49JhDwJtE2qLiNNWC1PojerHVFPTgA== X-Received: by 10.107.12.28 with SMTP id w28mr6617588ioi.209.1494476643124; Wed, 10 May 2017 21:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Wed, 10 May 2017 21:24:02 -0700 (PDT) In-Reply-To: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: Brian Smith Date: Wed, 10 May 2017 18:24:02 -1000 Message-ID: To: denis bider Cc: "curdle@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 04:24:05 -0000 denis bider wrote: > I agree it may be slightly preferable to use signed mpint, given that this > would be consistent with all other SSH key exchange methods, including > Curve25519, and it would be weird for Curve448 to depart from this. I think most implementations will implement Curve25519 and then, if they implement Curve448, they will adapt that code to work with Curve448. So having as few differences between Curve25519 and Curve448 seems ideal to me. Cheers, Brian From nobody Wed May 10 21:30: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 02354129534 for ; Wed, 10 May 2017 21:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBHrNjbD9tQD for ; Wed, 10 May 2017 21:30:48 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 DE8C01294C4 for ; Wed, 10 May 2017 21:30:47 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e193so7681027pfh.0 for ; Wed, 10 May 2017 21:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bT3d5NPVP0fgJwT2Cpi2Tl5poIRb7gt/KCcrlUCqtIQ=; b=bNz8UdZ6kgfL5y7nrodr0X+tZf3nC19BYf1g2Sn4KxMULyJimDd5LU06UhYDA99PDv TTapjaIej9jKkY7A5Bi69xsYwPujJcjdr+4MpF7kzDiUnnzFuhASgKjnzla1YMkHsJib +GSAp2KYF3RH4FD2RIZqFEcGnkCHLys/nZ0sw= 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=bT3d5NPVP0fgJwT2Cpi2Tl5poIRb7gt/KCcrlUCqtIQ=; b=GFws525f3xf1a5b3SBO4rFCAKetcdIjgeIcXAb4z+5zBSiK3CGURcFm3la4bRFiIwP 3HFdVB03il/zirK/CEaayLWD/u7jqT4BSs3F0yJHxE/dOqS3N/uW/sP4gQeujpfA+Ra0 hL4nr9RDwFaVEFyvrsw0ijQ8UwxuW978a9zLkflnSXDwJdAeX4L3HwcZoz8atCOjGCgi FzSU1+gH4NnKH2iVUUhSrcQeGGweEQ7WOqoLBPCM8SWms6G0VIhnAvlI0HugYhV8DzEZ ot56YqY9FbKhirMvhAeoJaNO5TuZWirYmiYxI4Lo9NUuV3WglTelUi+gveja0m0SCtyT tSQA== X-Gm-Message-State: AODbwcBWIqijD9PcWAW4N+1U02RiY1knfjuXizqauh9HRIb9jqPusADp Mx9XBITBUPTmog== X-Received: by 10.98.60.206 with SMTP id b75mr9966793pfk.19.1494477047394; Wed, 10 May 2017 21:30:47 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id m24sm802008pfi.129.2017.05.10.21.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 21:30:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ron Frederick In-Reply-To: Date: Wed, 10 May 2017 21:30:45 -0700 Cc: "curdle@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> To: Brian Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 04:30:49 -0000 On May 10, 2017, at 9:24 PM, Brian Smith wrote: > denis bider wrote: >> I agree it may be slightly preferable to use signed mpint, given that = this >> would be consistent with all other SSH key exchange methods, = including >> Curve25519, and it would be weird for Curve448 to depart from this. >=20 > I think most implementations will implement Curve25519 and then, if > they implement Curve448, they will adapt that code to work with > Curve448. So having as few differences between Curve25519 and Curve448 > seems ideal to me. Agreed. I see now where the encoding of K as an =E2=80=9Cmpint=E2=80=9D = is occurring (as part of the hash calculation used for key generation). = Since that is used for not only Curve25519 but also all other DH and = ECDH key exchanges, it would be a major change to do something different = for Curve448 here. --=20 Ron Frederick ronf@timeheart.net From nobody Thu May 11 01:56:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8E212EB86 for ; Thu, 11 May 2017 01:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 GhJFeC0n7EDd for ; Thu, 11 May 2017 01:56:29 -0700 (PDT) Received: from thyestes.tartarus.org (thyestes.tartarus.org [5.196.91.86]) (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 8416812EB92 for ; Thu, 11 May 2017 01:56:22 -0700 (PDT) Received: from simon by thyestes.tartarus.org with local (Exim 4.84_2) (envelope-from ) id 1d8jtR-0000xL-F0; Thu, 11 May 2017 09:56:17 +0100 Content-Type: text/plain; charset=UTF-8 From: Simon Tatham To: curdle@ietf.org Cc: mdb@juniper.net In-reply-to: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Date: Thu, 11 May 2017 09:56:17 +0100 Message-Id: <1494492688-sup-4596@thyestes.tartarus.org> User-Agent: Sup/git Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 08:56:32 -0000 In <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> you write: > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. > > Please reply to curdle@ietf.org with your opinions. On the occasion of an SSH implementors' meeting last year I did an extremely preliminary implementation of curve448-sha512 in the PuTTY code base for purposes of interop testing. It's not in any published release or even the daily snapshot builds, but you can find the code in the PuTTY git repository on the branch 'experimental-curve448'. The actual commit (which is based on last year's version of the code, but still seems to apply cleanly to current master) is here: https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=649480fd1997643b8a4246f0116268fc486ef331 and although I've now forgotten all the details, it certainly looks to me as if I tried to make it behave as much as possible like the existing "curve25519-sha256@libssh.org" kex method, changing only the numbers. Cheers, Simon -- import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib. sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!" )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9, 0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham ") From nobody Thu May 11 03:10: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 DAE8912EB8F for ; Thu, 11 May 2017 03:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 P4ekPO6xPs60 for ; Thu, 11 May 2017 03:10:51 -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 A040A127843 for ; Thu, 11 May 2017 03:10:50 -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=1494497450; x=1526033450; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nir7XdzMJqwH4ENq5VaUNO6I08pel5mJnuBBy4GVr/I=; b=Jn6+ZQm0tMhtDWlbsrgIdhbVJ/w/KCrBunT1Lr6NYE6RduSw4m4zi6i0 dPW/skdxEoGpL9K0/EEXjtlZTWuGRnZBd+wMObeohX9n59rSXWxVecwUV iO2S5joI8y64xDi7ek7Ov/jpemSlcP1Y5G+RfeDQtg0xE+r/GWy4iA5fx J7iGhviF+Z0qvT99i1KGsBu/L0+YHiBA2BP+IQTi4CDDKE2ht7DghMVyP f/9U0WqxTVKgTVVEybTF0gyYqvbt6lNBkWMYZyg+U3XJ/hOugjSmMCWZm ACXlfQqP3yWt6klPWWN1uL3So4RIzooe9a8IHX2uz+a3Yaoi5XqEH7cHi Q==; X-IronPort-AV: E=Sophos;i="5.38,323,1491220800"; d="scan'208";a="153789297" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2017 22:10:48 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 22:10:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Thu, 11 May 2017 22:10:47 +1200 From: Peter Gutmann To: Brian Smith , curdle Thread-Topic: [Curdle] Wanted: A valid PKCS#8 file with attributes Thread-Index: AQHSycWd5zgTPNs+GEO0ppgfX+m8E6Hu6gvo Date: Thu, 11 May 2017 10:10:47 +0000 Message-ID: <1494497413004.14332@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] Wanted: A valid PKCS#8 file with attributes 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, 11 May 2017 10:10:53 -0000 Brian Smith writes:=0A= =0A= >I've been creating some test vectors for Ed25519 and X25519 PKCS#8 files,= =0A= >some of which I've already shared on this list. I would like to create som= e=0A= >test vectors that include attributes, but I've not seen any. If somebody= =0A= >could share an example of a valid PKCS#8 file with attributes, especially= =0A= >ones that make sense for PKCS#8, that would be very helpful.=0A= =0A= Would PKCS #12 (containing a #8) do? I have some samples of that created= =0A= under Windows, however there's also the code comment:=0A= =0A= 11/6/13 - Windows sets these flags to what are effectively gibberish valu= es=0A= (dataEncipherment for a signing key, digitalSignature for an encryption k= ey)=0A= so in order to be able to use the key we have to ignore the keyUsage=0A= settings, in the same way that every other application seems to=0A= =0A= so I'm not sure how useful they'll be given that you have to ignore them in= =0A= order to be able to use the key.=0A= =0A= Peter.=0A= From nobody Thu May 11 06:36: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 57230129431 for ; Thu, 11 May 2017 06:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdsfQUFKbQBu for ; Thu, 11 May 2017 06:36:43 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307BE12EC69 for ; Thu, 11 May 2017 06:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YsdaRhjQmrIqlMXY0GDgL4JY6kJys4f7RE+xoRuExIM=; b=KcUSuhmiBEB3iCYZv3oM1BKw7b1byP1KUidy7f+1qNwMdvCz/LRuOLzp6Z9jquuOnHt2ro4HR5nvDP+VS0ib29jhrZE2S00nbnoAAjhruFs0w6xda5l/G9Jph0QXVp/cJdMAIiOUm8IwuZjBTWkTNymupYClbEhH/vLhfqQJhRk= Received: from CY1PR05CA0004.namprd05.prod.outlook.com (10.166.186.142) by CY4PR05MB2902.namprd05.prod.outlook.com (10.169.183.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5; Thu, 11 May 2017 13:32:38 +0000 Received: from CO1NAM05FT041.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::205) by CY1PR05CA0004.outlook.office365.com (2a01:111:e400:c5a4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 11 May 2017 13:32:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT041.mail.protection.outlook.com (10.152.96.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 13:32:37 +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; Thu, 11 May 2017 06:32:36 -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 v4BDWYq0027592; Thu, 11 May 2017 06:32:34 -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 7B18411446; Thu, 11 May 2017 06:32:32 -0700 (PDT) To: Eric Rescorla , Ron Frederick , "Brian Smith" , denis bider , Simon Tatham CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" In-Reply-To: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Comments: In-reply-to: Eric Rescorla message dated "Wed, 10 May 2017 09:20:37 -0700." From: "Mark D. Baushke" Date: Thu, 11 May 2017 06:32:32 -0700 Message-ID: <36528.1494509552@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(2980300002)(189002)(199003)(51444003)(9170700003)(2950100002)(76506005)(53416004)(47776003)(105596002)(54906002)(50986999)(229853002)(55016002)(6306002)(8656002)(86362001)(53936002)(77096006)(76176999)(7846003)(6392003)(54356999)(478600001)(305945005)(7696004)(2906002)(2810700001)(106466001)(6266002)(48376002)(6246003)(189998001)(38730400002)(4326008)(356003)(117636001)(7126002)(5003940100001)(8936002)(8676002)(5660300001)(81166006)(50466002)(39060400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2902; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT041; 1:FGKJDnZDyhO1hivfO28qCfuGxdQsq52sE1pCKhC/1XWgY5lgu12kjsrX060awP4btp0NeUp8RDKAX2mxoBaAfpG3vRUQOFhGsCFdSEnxZf64WYB5yvUxrwagc8H966Ij6HGdLVwYPxsgnStt0OD+G2EG6wyqLAXoIqGxma9KlMTD9/0H841ka86LC2Rtw1UEVK2eRA0tv7OsbCe8acNWB/R2nF5F0pn3XZdXkmO6QgrZn5sOPX1f964BhwS3d+czfaEXvRAf3m48O1e4I56LHkMSqtxAPG+zkncUYPHvJQD2BknpxXfOCTll+eAZW7aZv0XxXR6pgimTEMBhR6DWhUz1BcfycD+U4ocCc4E620m1dtyqlvekxRNpA84n307Uz98Z7hkIJWoDduATQD3RB04kD66RjH/ci6yriJr9tM8Cyo5P6PMN5LaYV6BZsBX7/vqk46ATperH/OCZBxokZjlG5GEODt3KWx1OTiLNVIiMYVOa6M636lmz1cJJmnkAAR3FDEmeUrfB7ggrZHZXw9ds7iHrFYx4d7NQssqHL+XxXEUsm4box9kV0PhE3bBJXMV4ylXicFkapwX2Q6r98pxkncz40bUpMPlZ9vXHZ99tN/5G3/D4wI+4CZsabHKL X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PR05MB2902: X-MS-Office365-Filtering-Correlation-Id: 148a9d25-8ac7-49d7-f682-08d4987230ea X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR05MB2902; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 3:iEWZlOm3JpaZfv9rZQRMNKEJofLMVr6LoV3x5MP3YzNA3MyzM3c5+o1CW0au+GjE/94xSH2fu1NtjYuJXaA4dpuBPfruEdL5SmtZWcJ0ZHuFdbijkP4Fsih+RY8POHBuvSPNhlPdHl+NowoH26ldhNE7C4PG7R4Wcb4pQEhZEf5GoGPHi9/bC4A2oQi4LANbiUBi8Dig4UnN0YOtgQjT0FkXWv7C/l8XKU1fwkbz/nKP1nzcHlM0ynvVgsD9jSEX+27ZcSeUQbNTfSra8QzS3TR90+D9FFIW+AGBXXlRcyH0ZpS6as8DJsolOX1LD6LSO5ULBw44Rx4sRki9Bs29xKhse7zloAv5RKwUXPW1rPv93R3syTKvOt3f9/jqr1+ON2Hb6ZShQSymwTOVfBEQgV59ba6Enjj//5cRaV7a8AdoFPh5Vl9EYTK0bG2zS5LrbxqEN4+Td3yFCM7A4ycCbQ== X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 25:y6yBy1R2eXxgyMvZ+6J39uawfMW5IpRh1nD7G932of7/wh6SRGp3hUe58i5PgwaHs2Lm0tzIrbMCPbY97zDZqB9wpMf6hztQnGJMPoWCzLDjfTamdKJAn2AlWJ+f7es1Yr3/Ssz/gBRJNrWlh1rxyiCeBxHhand28+D+GNRrWjBMcXGsYxdfKoSqN6ZaizHyr+NFHIl8H7MY+r1rNxhIQFTdkjTv9Kw3QdbkpDmE44FrmGywAnSoa9opZhXpsTpiScErOVppgj4TOjbVz9eTaxEwIQiedXi+8DFMr3EpNHy5yW5oISvBtrpFLwzayc7XjGi9Y7pJgs/4z4DSefH6AexukozpQwVp3FhH7sEVT/+OHkziBOgulPnwpbgQdaFEkPc+p693kRDeqfPln1i/b4Uxde5q6C1dfNTwblFMAgev8DQkVGm2CSWS/aGYvM30A2u3xcWGeqpeuAbM9M+qvvXi4EnZurypj7Icho5sKcE=; 31:677kC0IycnoldK9J7d0r2CN4HYJ4dUsS/jCu27sTSxD3LZqwx4y9OyMMyA99tPS5ZO60xvxrOJ2l1tddvJN2qA47XYsYmUYD9hGX9Rx160Y5dFErgXuIlh2pG9soJi2eIBd+dU8IUWTxQqioLfv9taEH8YPcbzImycyQEJ58Wo0WK64nMZ918SoI+T0ln2CGfrlqBc6WBJw7UdARWWWk7Ov8nyg9H4vZvObi30PVxgdPrMO/n7Qb36IJd/YzAdjcXrYIp5KSJ82lsa1ddwf1+w== X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 20:3Paz/HG+0uoOOafyG3sP+2ZZDdmRd1SOg+BtsI2rzldaU0z37hT1NC0W6AD914nYGAKUk1ivY6a3fqNKpZDh3pPwGuIGNw5ArPPEJ+alSAp9oKGPYJQPpof5xRWA4rCy7XlZbQYeDM0MF5CKV+TBSwKrn31r9F2/cqZ4UFyHbOW3D0bfrQldHr1d6GdtSJIVtmUcFF2D/9+TMXJwl0Jttx23bL6HB2HkBkN7T6U/BiRaekJW8kZA4sYVR3iHgi490Rj9M6eHzRUYHbZT/xXSmaSpHZxxER4Xnpi9ngXL4M8qHF90dPlMAJZ2QMqmuqB40S8lnKbJk5my2X+N10pmBL80LR+lUgWKs/T8sVJxxWMiCdt9SlQZHFZIpDKeWHR8c0imgArrgwsAY3tjH7vQJHCBd/lZiKrrmaYjWkLHpgpLHd1erkLH4ObYipateUBYes9Qcobod2Z2Ezum79ost6HAwnqN4xufXbzI//0bdAAYStLNHzzVPNzGnU/Visb3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13024025)(13018025)(13023025)(13017025)(13015025)(8121501046)(5005006)(3002001)(10201501046)(100000703036)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY4PR05MB2902; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY4PR05MB2902; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB2902; 4:8zsfbIy2kV29uGrLWHiKW4xNYZSlPsg5q5C/a/83WD?= =?us-ascii?Q?nEuRE1iv5NUzywQUQDvCtQWkOCoes5HTYhqtQ73OuUs5cBTn5t3GhepmU2Ur?= =?us-ascii?Q?T+uIPhepVWlapBdnjclvX8s4CguyqxcCyK0t5Y1xfhoKR+zGHQQPW271dcVK?= =?us-ascii?Q?vF3JpFvUC/WjDT8oFqeFfV2He+YostSWzXFGh6fyXXAvyAw9v2jLSVd8Tnyp?= =?us-ascii?Q?B/5hTTIVuygiVWQ/1wOSNIS1JzPwDvaWeNrW6gnaCQtd1c9V6XXqP+HuGIG0?= =?us-ascii?Q?DamaU5LskI5fTg+ukrlG8wt/ySNx6eXr1IRtYTKaVA3THK0/YEHL+KPGDV9L?= =?us-ascii?Q?jP1oJbqEWOuLFBM28kFbjrZaf8N2KEkHey6RC8nxeZ1uIwmEJTpKyb16eeOB?= =?us-ascii?Q?JtfAUkvEkpjedQjbebunARs0x/c4nv8HJ3eShFbYYzZjeAuCJoaINPaNVCLv?= =?us-ascii?Q?BegKQB7HADO6IcRrEreX93IIFU30t6t0Cv9uk9gluEA58LoHoOpuaxcmOS4e?= =?us-ascii?Q?+hveZKeXS74yZCfoYMPMZnBXYR+6lEc/ib3VQOERy16aCrpWAHpIo1VcHIoP?= =?us-ascii?Q?5d6RqEekrLnO5wzYZ+8KUnIDFNd/SLsr3BaLO1JXAjLFYJNC282Tba7jiZvg?= =?us-ascii?Q?T/v34CsigZXO2YXfHRh7De8WHGG5Blk50Qop5/UAUcgvU5YF0dPVJtRJid9e?= =?us-ascii?Q?ddS4EPQ9deJ/4AU4QhVgIUQ9uGYsVQTjt596oUmsieZxjOzyfEfFRH9WSDUB?= =?us-ascii?Q?0RZ7H9Zx2Z4XmT34SjT0R2p2bkKhek/74BDEdcAfuwQWk5OYzsZO3Z3gDbXL?= =?us-ascii?Q?kqDRNUL56rlwQR7+0dBWYK/LshuQZg9laKvjj/ifGggokpLh66aC9otLYRvl?= =?us-ascii?Q?P/86P5zGWQCtbF+1a2RlDBmX2D2vXBsUqVulIIVG0gb9cNF8T2G+wiY8NLn7?= =?us-ascii?Q?Lq8uvKbtwC/IeVX/n4xLqJG/STTWRAEmqTVzHxoKjjZMpbQma5w7pCGTsM2o?= =?us-ascii?Q?aJ4Q0u3MBFyokgPRJ3JC4sdKauL89dQ+3ymS8k5Q+aBuSJi13CMpPzArkXnt?= =?us-ascii?Q?S1JuKvYPf9yjq8iffOoyJho7Vocv/e9ik6+Ovl/h+xOcJpq33By2YpT/Bwxs?= =?us-ascii?Q?VIrHO/+x5mQ+Yk56/qZNm7OUsRh7bixidWodAjxFLrQvvqqKNCGnymR1BrdJ?= =?us-ascii?Q?XWl3K2qi+CbzMw3IVqYzSMEaob+k27tPxJFnyC+tlenmMi7y2CcRjpgRr+BU?= =?us-ascii?Q?ElqLz4UWYnKdFWeVg=3D?= X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB2902; 23:Kgh4Iy3DjsPoTjiAkbBj0K9spzBL5U9oKggvuxIKT?= =?us-ascii?Q?y0bvC/qYrMJPUpjtU8Cv2QbVlQSN3VtkFZwEr+G6PffWOu1z/do/ehgD+Tam?= =?us-ascii?Q?AkpevMRfqCCGtmdUsGvVXZqJSVs4epz9XjaIzfxQKhRBQrz5vHuTGW81CdUs?= =?us-ascii?Q?B6FB6q8hHd73j/KxUa+unlgF8BRCGtXdsLaoa6WT2suBrMajGfTnvtUK6UrT?= =?us-ascii?Q?BmCACi8i5ACTV2zZ2qw9jmgWfwga+TITrA6/NSfnQNMtE/RZOiMmz2Ig+MRF?= =?us-ascii?Q?9O0tPhMGjvkiEPpGAkJrW4ZG85lftQ19Pc0FzwVQNGPBTHoYrptIz9e0pyku?= =?us-ascii?Q?+ryY6xbRdrTw65ywilc+kOLYLtbe+b7rbeKIlCHmOe6QiXB/XG7TatmPkErE?= =?us-ascii?Q?TRgkE4louKGng8wimN/5Lyb5z0y5EkCtTnF9SyCtb+bJkaO5aGDvHSotqE9f?= =?us-ascii?Q?UfCUMdHrUgnCwzwjsKBJrSXQtAAJ/MZ4iFEQ0dCXYHUdeOzc5jv4vEtxt3P2?= =?us-ascii?Q?gU/dvc5uEGz6k8s6vkh7T+EIq4jHOReh+ZWQA+hsT4G3W3lbPB44zACPfdaB?= =?us-ascii?Q?P/kTc5GTHKse0DoK9NrsDcI862p/MWPNxtbSDD9JZcQH0/EBVq9hGS+2zvnj?= =?us-ascii?Q?+ZnzaC+oSJY1n6SCaHBpuMqDEr45DAoDsbjsAq9nFZCYg73eQdpClyWAnpQQ?= =?us-ascii?Q?hVA5dA50jXv+Ps2HxTRs+EolrfFqr8eDM2MwJkwlcz3g1FRS9mK8kEb7M5ww?= =?us-ascii?Q?Jj+q+xX7eNwBtO/ZLJq7g92I8s5jUHTwuTY5iWEiGwB6Ve33xlUEa/vg6KhL?= =?us-ascii?Q?CpEPaGGukXQIfAhHRk9K11/oRKzEOKV1kKsEaVIJS/cRJfamZygaQuMrEffr?= =?us-ascii?Q?KbQbGxtUeRveaybZIIJPobTb1LSfTvLtshCDO+mnS4elM2/LWKtphmxLscUB?= =?us-ascii?Q?SoJu/Wd/JilRDcTNywg7mhVl+KF8oMiU92ABf7NY0PwCKhNRD9/x3Rfzxr1Y?= =?us-ascii?Q?eKAYL+UDANx0AWdtrT2v1nkM6M6LPWWy5LQCJCa5kwRC9yZDBFmih/AO1xmO?= =?us-ascii?Q?wJneSRftVyQm+K6ZmopKMwKQCOhivpwkVSDyzepdMQ2Mi3cvB9bCIN84/jzV?= =?us-ascii?Q?ijq7EXanxi+hf228RkdzZIcy+/BkC3jP1MI7ZilZKPKVv2D7/ipLoWYKezDZ?= =?us-ascii?Q?MPP/4oz+Jf1cNZKGlE/ozKGAe1jBNCLXdO+Uxw7048pS6Fj//U+QTeGvOyti?= =?us-ascii?Q?DAPDwXKzYaVgbl4avF/fYGVE51D2tT7JKGTHlN6dIWpoE7SzzZlN1YK4qXZr?= =?us-ascii?Q?y0xhGZEijbJ+gW8QFxFqhk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 6:F2lgybfrGeQ7Ab6k6e0Uu5NyKjZADjWhlaSABvByAgLgGxiupz0IxD3gLwCEFUXDAX42BetyJPDEm8BPiNW1YKNn+eQhcNiJRS6If1aSajQMQ3cZtgknXcC1XdtBkmKtIIGi5W1pPodUhcLXQd0JtaxIimJ90DWVfc+o3/36KH3yRG2BJ9T7IdVyxBHI302e7NMc1ResZR93Q/e4HnBthG1BO9QMt0v+Nyxnt06E+rgpiXqwMHz5DN2zosh0fB3JL0hwmRB68HvCArKVXO4ENnLg+2rWh2rTkt/RpsxgMehxi8JE0fPniU+3h8He+Ckt2A/rB3WZys/clNZQLON+3JyLH4WUlBLnSrfaOJYGae2ZTficzu/ChisTv8RbVEHqg5GkKK9qniXV7SLQunuN/YLJMJTLeECxbCpcvtHgJpBTIQI/vgH7ZzNcdbdnlv6BzhwHVlTMRQ9mPgiZ2lrrjBzVeZ/QxMHo3iVpuW7TqN31ibw9WmiDn64Sss+YFA7aM4OIEvQuEun8SRdtfeW5ovtA66Om5wCDIfapnA5Eaw8= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 5:5fKX/bc2F4Ec5mO5f7ic11+sUM4sER6XBERS5U+0pMae3ziNVFwVS8cOOhvtgLONWGYT78EeLNXv0Agr0V7rUo7WX+rFCB7ILykQQZJSPMty8xo/Nz6u7zvjL1Yw8W+dTgkUqK4NRqT+I2wBCVs6Y7rAlITq7aOxMk34xsx4DopAZbK0drEh47YZp3+NGg87od1VX2TmHlBMvacZyqHgIICOY2zLQt7Eqlnui2irwH/om8NbrCgFXMXfP1QBEeutMu/H7Tc98lX83j1wiAy3tQOAAFYKfCM77Yf/5wyJVPUK5B+qwzTTQTEEAFtk3/hYPeQrti1qAdwQRqDGT7gKhqeOCcB+6mHJOSZHTLli3MO93YxBJVu0r8zOG5a+eh4ZD2jbUY/TudPCgRP+suea1eQWBh2AjhV9IaZkw8b8/KDa9W0+SjGGuI0ffftHq82g38Krq3pWDCmgz6OM3VKfdCdCcigbCloSAMONtBvL8yXNWObiDDazBHdreupRFBAo; 24:/s3ZbLTL77k/VwrWzMBh1osWH1qBkUUX/OcPa8AffxtUAOpSG13UME5L3qVI4hGYma8a8XCw+XGequPnNHbxbyXAr803qFDB3BbM5pPKd1g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2902; 7:ke5I83yxoOQ0r//GkpktxacsmJDlBS86M/daTp5ZvQKDKvrmPACcprQAI0vL+6ozJKaXT44X6e3ecJ3SS6HXwZ+dPAibhEOzkfgbKm2dLAAA2lfSLJLB1tvMVcKxEQhmoC4YSDD/n68vzGjJkZmFeq7JExMXgxRmWhjxY0MJciUsQBdghDn7xRh3JihQn1+/8pOQBYRjaWsKjtt0lPD1YD2Tg0LVjpEDAsb/cBqpcEwgtmetKn+pL1nUX0S/ermXiAsQPiEhYleF+DMaNrrOUx5L8Y+25Y3K32TKyhcGgkOlUJiWtZLe7LEkTKsqM09uxFAKQWU9/H0vPRl6+6uo7w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 13:32:37.7839 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2902 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 13:36:46 -0000 Hi Eric & Ron & Brian & Simon, Given input from folks so far, I think it would be better if both Curve25519 and Curve448 continued to use the "mpint" format for K when generating a hash even though this is not what RFC7748 suggests. Would it make sense to include the following text to the end of section 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. to help clarify the differences between RFC7748 and what is happening in SSH? Much of this text is borrowed from what Ron Frederick has written to me, any remaining confusion is my fault. I think that the above text should help clear up the confusion that Eric noted in this section of code. If there are no problems with this text, I will release the -05 draft with it. Thank you, -- Mark From stefan@stbuehler.de Thu May 11 06:18: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 339F3129B04 for ; Thu, 11 May 2017 06:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 (1024-bit key) header.d=stbuehler.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfjBFvDf6wis for ; Thu, 11 May 2017 06:18:26 -0700 (PDT) Received: from mail.stbuehler.de (stbuehler.de [88.198.35.59]) (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 67D1C129B02 for ; Thu, 11 May 2017 06:15:39 -0700 (PDT) Received: from [IPv6:2001:7c0:2049:1d4:14b7:34a8:44f4:149e] (unknown [IPv6:2001:7c0:2049:1d4:14b7:34a8:44f4:149e]) by mail.stbuehler.de (Postfix) with ESMTPSA id 24CBDB80135; Thu, 11 May 2017 13:15:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1494508532; bh=pV8vDy1x/7V/upmia59nR6e2khWUxXG9C5wAmE7kQLw=; h=Subject:References:From:To:Cc:Date:In-Reply-To:From; b=eFBnPchq59deaL06NLrDr35TjvbzKxjTxULaiQjZggxWDgPvS3VlOEON6T4Ar3UuY xf12X1vQGlgtcuuIsNkId/uLxoumwuxWwRr2Du+uQjoP+M8lvPiW5dv8QpZmt9kiIO bcLJxk5oU/nomgTob9Se5y81PCgPBc/+m4navYDE= References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: =?UTF-8?Q?Stefan_B=c3=bchler?= To: "curdle@ietf.org" Cc: "ietf-ssh@NetBSD.org" Message-ID: <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> Date: Thu, 11 May 2017 15:15:31 +0200 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: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 13:49:20 -0000 Hi, On 05/10/2017 06:18 PM, Mark Baushke wrote: > Hi, > > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. While we are on the topic of converting the shared secret bytes X generated by Curve* to an mpint, I'd like to point out that the draft-ietf-curdle-ssh-curves-04 is not clear regarding leading zeroes: > If X has leading zero bytes, the mpint format requires such bytes > to be skipped. In this case, the length of the encoded K will be > smaller. If X has one leading zero byte, and the highest bit of the second byte is set, K will be exactly X, not shorter. Maybe it would be better to describe an algorithm for the conversion, like: - trim all leading zero bytes - at least one byte must remain ("Clients and servers MUST fail the key exchange if [...], or if the derived shared secret only consists of zero bits.") - if the highest bit of the first byte of the remaining string is set, prepend one zero byte Or as pseudo code: k := x; while (k.length() > 0 && k[0] == 0) k = k[1:]; assert(k.length() > 0); if 0 != (k[0] & 0x80) k = '\0' .. k; cheers, Stefan From nobody Thu May 11 07:11: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 DE6CE130141 for ; Thu, 11 May 2017 07:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjeri609b0-4 for ; Thu, 11 May 2017 07:11:25 -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 E21F213148E for ; Thu, 11 May 2017 07:05:22 -0700 (PDT) X-AuditID: c618062d-481ff70000000cf0-1e-591482dd3f80 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 1C.D3.03312.DD284195; Thu, 11 May 2017 17:27:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Thu, 11 May 2017 10:05:16 -0400 From: Daniel Migault To: "Mark D. Baushke" , Eric Rescorla , "Ron Frederick" , Brian Smith , "denis bider" , Simon Tatham CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Thread-Topic: ssh-ed25519 implementations Thread-Index: AQHSylsYe0kaNRFXjUKb2lX66nDkWqHvIbRQ Date: Thu, 11 May 2017 14:05:15 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDA5B0@eusaamb107.ericsson.se> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> In-Reply-To: <36528.1494509552@eng-mail01.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyuXRPiO6DJpFIg2mt1hY/mlazW1yZeojZ YuvCWcwWx8/NZbZY8focu8WHe4/ZLLruXGezWLX5H7sDh8e+hsOsHjtn3WX3WLLkJ5PH9aar 7B4LH/Ywely8pOwx+XEbs8ftdxeZAjiiuGxSUnMyy1KL9O0SuDJm3pvCWHCLr+L7rQ2sDYyP ubsYOTkkBEwk7l3cx9rFyMUhJHCUUWJz0zsmCGc5o8ScrrmsIFVsAkYSbYf62UFsEYH7jBKN XyO7GDk4mAXCJJr36IKEhQU0Je59fcEMEhYR0JKYe8ARohqos/cOWCeLgKrE1IXTWEBsXgFf ie0H9rFDrNrIKPHl2y42kASngJlE74HDYGsZBcQkvp9awwRiMwuIS9x6Mp8J4mgBiSV7zjND 2KISLx//Y4WwFSX29U9nh6jXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZ haRlASPLKkaO0uKCnNx0I4NNjMAYPCbBpruD8f50z0OMAhyMSjy8D2SEI4VYE8uKK3MPMUpw MCuJ8GplikQK8aYkVlalFuXHF5XmpBYfYpTmYFES551w/kKEkEB6YklqdmpqQWoRTJaJg1Oq gdFDJy1+7td1R5yPvJmw9MOED0zyYmubtD9FNwrtD5t/a6lWTnjJ0sOXVkzKtrsg1nPv2h/n jE1MoglHdVZ/kLv675eS4f4n3MePiN4UrjOV5zmWt+GcukO/7emH14zMNUo6eKpC7KrKLLd+ zWv21I3cJH3kg65K8/Lz9md/fvh7YsL1qN6pf4qUWIozEg21mIuKEwGB1baKvQIAAA== Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 14:11:28 -0000 I believe it is nicer to have Curve25519 and Curve448 should be coherent. = The text is clarifying. -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Mark D. Baushke Sent: Thursday, May 11, 2017 9:33 AM To: Eric Rescorla ; Ron Frederick ; Brian= Smith ; denis bider ; Sim= on Tatham Cc: ietf-ssh@NetBSD.org; curdle@ietf.org Subject: Re: ssh-ed25519 implementations=20 Hi Eric & Ron & Brian & Simon, Given input from folks so far, I think it would be better if both Curve25519 and Curve448 continued to use the "mpint" format for K when gene= rating a hash even though this is not what RFC7748 suggests. Would it make sense to include the following text to the end of section 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. to help clarify the differences between RFC7748 and what is happening in SS= H? Much of this text is borrowed from what Ron Frederick has written to me, an= y remaining confusion is my fault. I think that the above text should help clear up the confusion that Eric no= ted in this section of code. If there are no problems with this text, I will release the -05 draft with = it. Thank you, -- Mark From nobody Thu May 11 07: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 B4C3F12EC44 for ; Thu, 11 May 2017 07:21:26 -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 Q-X2E3n_mDH6 for ; Thu, 11 May 2017 07:21:24 -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 8E62B12F255 for ; Thu, 11 May 2017 07:14:36 -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=1494512073; h=from:subject:to:date:message-id; bh=wcKhGDPPXVlfKhhTrvYXyy90JJIGT1DVf6azKxi2Uxc=; b=ij87UCZ/ZwgaTnc/stYwcu503WylCmT6xmD67Y0Nf3JAZtw35bYsTNRLNGq8C95NHUhPTKXkYq4 aHT9GX4eMcTqPMclXMAXU8tUtXXM12zLj9L4aq9j0g7lDJjoWz2NhJAITBnAAzGmdRxT/fbuUDw9o Fiw3bhNCTEb6fqMCvtjKEvLM+sNvQj46oMCoMhiEKa2Fquysi1KZOYjoxXVG1S85bFMioIZfioMcH NBZOszq9dw/utcVH/mAnLHbGEhH57xuJLrPg5VkIUyODzt3PuO6HUEQl2x1U/4zxH/gcRJ9XpBmkS Te5YQqkRRIpkHmxUeOrxRA56lNYNWWPHUVCA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 07:14:33 -0700 Received: from Hebrews (209.180.172.224) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 07:14:20 -0700 From: Jim Schaad To: 'Daniel Migault' , "'Salz, Rich'" , 'Russ Housley' CC: 'curdle' References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD941B@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD941B@eusaamb107.ericsson.se> Date: Thu, 11 May 2017 07:14:38 -0700 Message-ID: <00c001d2ca60$f0136600$d03a3200$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJVRMoP3cq4mnmyrtsRHkX9DmppwI228pxAWt1TpUBWsHjHAN7FOQdAZi7CHQBRXVEwwHSbWjqAmZMeyEB3QA12gFghW5NoWux9CA= X-Originating-IP: [209.180.172.224] Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:21:27 -0000 Given that they were in the public arena and that they might be = implemented in the future, I would rather not have them re-assigned to = some other value.=20 The reference is going to be back to the -03 draft of the document. = Since these never go away anymore I think that this is ok. I would not = be adverse to changing the description to be "Reserved for..." Do you = think that makes sense? When doing new registrations, this will simply be an IANA request. When = the document goes through processing to the IESG the chairs would need = to designate the experts to be consulted. For simplicity I would = suggest Russ and myself as we are the experts on the S/MIME and PKIX = registries (actually, just saw that I am not on the PKIX one) so a = consistency between them would be maintained. Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Wednesday, May 10, 2017 6:46 PM To: Salz, Rich ; Russ Housley Cc: curdle Subject: Re: [Curdle] New Version Notification for = draft-schaad-curdle-oid-registry-00.txt Hi,=20 I thought that the pkix draft did not consider prehash variant. Do we = want to allocate 114 and 115 ? If so which reference will we indicate ? = Maybe a clarifying note would be needed.=20 In addition, should we make explicit who to contact when new OIDs should = be added ? Yours,=20 Daniel=20 -----Original Message----- From: Salz, Rich [mailto:rsalz@akamai.com]=20 Sent: Wednesday, May 10, 2017 8:52 PM To: Russ Housley ; Daniel Migault = Cc: curdle Subject: RE: [Curdle] New Version Notification for = draft-schaad-curdle-oid-registry-00.txt > no reason to consume a short OID for an ASN.1 module identifier; they = never get transmitted. I suggest we save 120 for an OID that will be = transmitted. That's an excellent point and the draft should reflect that. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Thu May 11 07:40: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 B1DF812EC61 for ; Thu, 11 May 2017 07:40: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, 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 eh8BoDzKeFkR for ; Thu, 11 May 2017 07:40:44 -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 5ED8012EBD0 for ; Thu, 11 May 2017 07:33:50 -0700 (PDT) X-AuditID: c6180641-45bff70000000cb9-32-59142fee97e5 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id BF.25.03257.EEF24195; Thu, 11 May 2017 11:33:37 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Thu, 11 May 2017 10:33:47 -0400 From: Daniel Migault To: Jim Schaad , "'Salz, Rich'" , 'Russ Housley' CC: 'curdle' Thread-Topic: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt Thread-Index: AQHSydNo5xLHnrIk0Eue9R1F/QEgUKHukQEA///IoOCAARefAP//wTUg Date: Thu, 11 May 2017 14:33:45 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDA5EA@eusaamb107.ericsson.se> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> <9FF7BF72-6AFB-41F4-B413-741F4833747C@vigilsec.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD941B@eusaamb107.ericsson.se> <00c001d2ca60$f0136600$d03a3200$@augustcellars.com> In-Reply-To: <00c001d2ca60$f0136600$d03a3200$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonSvejvkikwdrrrBZbF85itnj14ia7 xerp39ks/m/pZHFg8Zh8ZAGzx8Y509k8liz5yeSx6s4X1gCWKC6blNSczLLUIn27BK6M1uW3 2Au+SFfsa1jK0sA4Q7qLkZNDQsBE4mzrPKYuRi4OIYGjjBJb/8xkh3CWM0psX7GHHaSKTcBI ou1QP5gtIlAscWnOVDCbWUBOYv2b/4wgtrBAjMSEjeuhamIlNv5cxAZhu0ks+tzDAmKzCKhK nNu+H6yGV8BX4tPKPVDL3rBKvH/7AayIU8BBYnXLKrChjAJiEt9PrWGCWCYucevJfCaIswUk luw5zwxhi0q8fPyPFcJWlNjXPx1oKAdQvabE+l36EK2KElO6H0LtFZQ4OfMJywRG0VlIps5C 6JiFpGMWko4FjCyrGDlKiwtyctONDDcxAqPmmASb4w7Gvb2ehxgFOBiVeHgXPBGKFGJNLCuu zD3EKMHBrCTCq1IqEinEm5JYWZValB9fVJqTWnyIUZqDRUmc9135hQghgfTEktTs1NSC1CKY LBMHp1QDY7d+W1tz4rxgtf7gOTunSnTHKbKFt5iEL2y4X/5YSU781If8twbuczbX6XXPnPxl TZ/H99/tD8Q7dpye3r8z9krBNAO7xQZ8Zbsz7+oZeZ96ULjv48Ep8toHns3SM13rttnD8vpB hn/r9r7Ni3koleOgF3vg4ctZoUwqDXfmuZ9+sSLx0yqhrUosxRmJhlrMRcWJAEK/Nj+WAgAA Archived-At: Subject: Re: [Curdle] New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:40:47 -0000 SSBhbSBmaW5lIHdpdGggeW91ciBzdWdnZXN0aW9ucy4gSSB0aGluayAiUmVzZXJ2ZWQgZm9yLi4u IiBpcyBtb3JlIGFjY3VyYXRlLCBhbmQgZWFzZSBtb3ZpbmcgZm9yd2FyZC4gDQpZb3VycywgDQpE YW5pZWwNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIFttYWls dG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgTWF5IDExLCAyMDE3 IDEwOjE1IEFNDQpUbzogRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNv bT47ICdTYWx6LCBSaWNoJyA8cnNhbHpAYWthbWFpLmNvbT47ICdSdXNzIEhvdXNsZXknIDxob3Vz bGV5QHZpZ2lsc2VjLmNvbT4NCkNjOiAnY3VyZGxlJyA8Y3VyZGxlQGlldGYub3JnPg0KU3ViamVj dDogUkU6IFtDdXJkbGVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2NoYWFk LWN1cmRsZS1vaWQtcmVnaXN0cnktMDAudHh0DQoNCkdpdmVuIHRoYXQgdGhleSB3ZXJlIGluIHRo ZSBwdWJsaWMgYXJlbmEgYW5kIHRoYXQgdGhleSBtaWdodCBiZSBpbXBsZW1lbnRlZCBpbiB0aGUg ZnV0dXJlLCBJIHdvdWxkIHJhdGhlciBub3QgaGF2ZSB0aGVtIHJlLWFzc2lnbmVkIHRvIHNvbWUg b3RoZXIgdmFsdWUuIA0KDQpUaGUgcmVmZXJlbmNlIGlzIGdvaW5nIHRvIGJlIGJhY2sgdG8gdGhl IC0wMyBkcmFmdCBvZiB0aGUgZG9jdW1lbnQuICBTaW5jZSB0aGVzZSBuZXZlciBnbyBhd2F5IGFu eW1vcmUgSSB0aGluayB0aGF0IHRoaXMgaXMgb2suICBJIHdvdWxkIG5vdCBiZSBhZHZlcnNlIHRv IGNoYW5naW5nIHRoZSBkZXNjcmlwdGlvbiB0byBiZSAiUmVzZXJ2ZWQgZm9yLi4uIiAgRG8geW91 IHRoaW5rIHRoYXQgbWFrZXMgc2Vuc2U/DQoNCg0KV2hlbiBkb2luZyBuZXcgcmVnaXN0cmF0aW9u cywgdGhpcyB3aWxsIHNpbXBseSBiZSBhbiBJQU5BIHJlcXVlc3QuICBXaGVuIHRoZSBkb2N1bWVu dCBnb2VzIHRocm91Z2ggcHJvY2Vzc2luZyB0byB0aGUgSUVTRyB0aGUgY2hhaXJzIHdvdWxkIG5l ZWQgdG8gZGVzaWduYXRlIHRoZSBleHBlcnRzIHRvIGJlIGNvbnN1bHRlZC4gIEZvciBzaW1wbGlj aXR5IEkgd291bGQgc3VnZ2VzdCBSdXNzIGFuZCBteXNlbGYgYXMgd2UgYXJlIHRoZSBleHBlcnRz IG9uIHRoZSBTL01JTUUgYW5kIFBLSVggcmVnaXN0cmllcyAgKGFjdHVhbGx5LCBqdXN0IHNhdyB0 aGF0IEkgYW0gbm90IG9uIHRoZSBQS0lYIG9uZSkgc28gYSBjb25zaXN0ZW5jeSBiZXR3ZWVuIHRo ZW0gd291bGQgYmUgbWFpbnRhaW5lZC4NCg0KSmltDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRGFuaWVsIE1pZ2F1bHQNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDEwLCAyMDE3IDY6 NDYgUE0NClRvOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgUnVzcyBIb3VzbGV5IDxo b3VzbGV5QHZpZ2lsc2VjLmNvbT4NCkNjOiBjdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbQ3VyZGxlXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNjaGFh ZC1jdXJkbGUtb2lkLXJlZ2lzdHJ5LTAwLnR4dA0KDQpIaSwgDQoNCkkgdGhvdWdodCB0aGF0IHRo ZSBwa2l4IGRyYWZ0IGRpZCBub3QgY29uc2lkZXIgcHJlaGFzaCB2YXJpYW50LiBEbyB3ZSB3YW50 IHRvIGFsbG9jYXRlIDExNCBhbmQgMTE1ID8gSWYgc28gd2hpY2ggcmVmZXJlbmNlIHdpbGwgd2Ug aW5kaWNhdGUgPyBNYXliZSBhIGNsYXJpZnlpbmcgbm90ZSB3b3VsZCBiZSBuZWVkZWQuIA0KDQpJ biBhZGRpdGlvbiwgc2hvdWxkIHdlIG1ha2UgZXhwbGljaXQgd2hvIHRvIGNvbnRhY3Qgd2hlbiBu ZXcgT0lEcyBzaG91bGQgYmUgYWRkZWQgPw0KDQpZb3VycywgDQpEYW5pZWwgDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTYWx6LCBSaWNoIFttYWlsdG86cnNhbHpAYWthbWFp LmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1heSAxMCwgMjAxNyA4OjUyIFBNDQpUbzogUnVzcyBI b3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT47IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWln YXVsdEBlcmljc3Nvbi5jb20+DQpDYzogY3VyZGxlIDxjdXJkbGVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSRTogW0N1cmRsZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zY2hhYWQt Y3VyZGxlLW9pZC1yZWdpc3RyeS0wMC50eHQNCg0KPiBubyByZWFzb24gdG8gY29uc3VtZSBhIHNo b3J0IE9JRCBmb3IgYW4gQVNOLjEgbW9kdWxlIGlkZW50aWZpZXI7IHRoZXkgbmV2ZXIgZ2V0IHRy YW5zbWl0dGVkLiAgSSBzdWdnZXN0IHdlIHNhdmUgMTIwIGZvciBhbiBPSUQgdGhhdCB3aWxsIGJl IHRyYW5zbWl0dGVkLg0KDQpUaGF0J3MgYW4gZXhjZWxsZW50IHBvaW50IGFuZCB0aGUgZHJhZnQg c2hvdWxkIHJlZmxlY3QgdGhhdC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpDdXJkbGUgbWFpbGluZyBsaXN0DQpDdXJkbGVAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3VyZGxlDQoNCg== From nobody Thu May 11 07:46: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 1DE3B1314DC for ; Thu, 11 May 2017 07:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mG7gTpwE2Ng for ; Thu, 11 May 2017 07:46:06 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A36412EBA5 for ; Thu, 11 May 2017 07:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=//2uhS/xEAJNL5YxufE+luly9MaUNcnKjxgcQMD6gmo=; b=jZZPxAz4opSlUmtdFO8IgcU7KCB86Upx8obBDNLBmEYdOLBM9kUnMhvkduOBgjq+QhGOoYlK39eVgBH0cCqvpGhoAPvVipgtmquTYpaAji84FcpKeiQHs7aQil5vxNQLtewB+lPHlNibkfzaNi8VIfpFbD+gXCNfQilLGsX87t0= Received: from DM5PR05CA0013.namprd05.prod.outlook.com (10.173.226.23) by BLUPR05MB259.namprd05.prod.outlook.com (10.141.22.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 14:39:20 +0000 Received: from BY2NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::208) by DM5PR05CA0013.outlook.office365.com (2603:10b6:3:d4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 11 May 2017 14:39:20 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT034.mail.protection.outlook.com (10.152.100.171) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 14:39:19 +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; Thu, 11 May 2017 07:39:12 -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 v4BEdBr6007206; Thu, 11 May 2017 07:39:11 -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 3A22111446; Thu, 11 May 2017 07:39:11 -0700 (PDT) To: =?UTF-8?Q?Stefan_B=c3=bchler?= CC: "curdle@ietf.org" , "ietf-ssh@NetBSD.org" In-Reply-To: <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> Comments: In-reply-to: =?UTF-8?Q?Stefan_B=c3=bchler?= message dated "Thu, 11 May 2017 15:15:31 +0200." From: "Mark D. Baushke" Date: Thu, 11 May 2017 07:39:11 -0700 Message-ID: <47874.1494513551@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(54906002)(6392003)(7846003)(8936002)(356003)(2950100002)(6916009)(2906002)(55016002)(38730400002)(189998001)(478600001)(53936002)(305945005)(6266002)(2810700001)(6246003)(7126002)(50466002)(110136004)(47776003)(48376002)(8676002)(86362001)(229853002)(54356999)(5660300001)(81166006)(106466001)(76506005)(105596002)(77096006)(117636001)(7696004)(53416004)(4326008)(5003940100001)(50986999)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB259; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT034; 1:P4f9gpv4p7xtAAiTWGlOumrMKp65F9Iv6BOqfPvY38Yh9HKNyCDA0KklHoxKnBYh1/xeqc0fq0E+6bC8/DM40epPWdlqjSIYQjMQoDaWp7MfuN71wPjq/5EvFpbzoUIiz3BZOR72bWP7MtFY4rzglWB30twukC/YKJTFZYVOAu0jBYZsA3izde64L+BxSWc3Bx4+6RQnlVQtHCy2EhihEunDK6YkW7Kg/Z3KW8GUqUhW3S3zGpEp0XQKzPBGf+cmC8eGvfLkPo3fTrRuZIxv/5xrTxdyJNDVXCYmIqGQw+XXcDZP7igfQvjLho0zGXJ+b3Kn07VtLbF4UpicTDaqMyBv6PeCAYTOvGEMI/gQgabVvLa78EPnt2ah2MA6NJZu/i2O8NJ43xLt676kC8os6wY1K2H3zzQ9lGSmFnquO8cduTsnhjc1mnZpzcdl9KpHM0EN5Uh1GR24L1Q8qElmKkn3Z+fwUtK3nug/bLpV9iKMpXRBlNPhUjVW52e10PSZO2KQrjTuTLnyIOflz+8Ep9cFweAOa41iDDtQVb4mAGy7ULJOjPlGRBZL42ZRjqH16ZpqPGMzjYZYBAr8Uu+YVu6LS7FuIxs+M+ItEWm9aD0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54dced12-f4e8-40dc-626f-08d4987b8219 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR05MB259; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 3:OttlBNbKMGaSwohwJjSSMrSwQdPykTpLSf2Ypd2oXUa/cfRKMeS7hRuWN5TWQ8Ud/xqqcU++uIm9wcdNGeTY+gWhg3JJQgHlt9YjHtca1EBFrDXcXyoO5PZXdwdKZN+A/fjS9A/+ZohCpQchFuB3qw9vPtyBbfbokwoSU3T7GQhcuX47pSbrybDzQ2LzzMd3/HQTUpyUMyoPbXnFdoXsgcMk13so3HRXr7rEaB49zwtd6omHACyjE3v5ya15UBTZ5UFPX+42p45O2LWUnmM2IfUonScwiHJpgeUYvJwcoF7vdrxr4Oah0uGIosy14tmzQGhiCNSVcMMdZzMtkFBIMKZqxIa7K2LrqtRiWAZ8t4MAMppyEaI1IqDHZUMjAVcPvyKvPEZ/FHaob0VZg6odvdewLSJoN0jG3pDpPwtgkF8LUHXtrKeUH/ElvFCqGcoLl3H5k7Ga7HDl+mSAiF6BSA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 25:TLXOtK6Pg/CIZ6ckJFsvFVwmyow2uh+P/TE86IATCynm4Id40FLhkNWGCwR5+a0mYXIje63wV2RJ1w3qVFSoFbKMolTLTq+hnPCle7llFg/D3zOm7zkNdPU8bPWqal14xXJsQs7k2Gp1SMaK1qC/1mZHmcP7VxqFHRcAgxv44KSEqUah9hcEcbd3Ait3Rpeb7rP6NOnbp4m5m7awaQxozpqxeiA2CbZ8JTuNmOoEBH7E3clULAhbVC9kH2flOwTbu70gxmnowQ+Lso2zUADeqy0m82m1/FArKJIsOsnYTytglsIS/RpedwwZHstjHc5WyLG18mwPlayq3S+sQIpvxvqegNc2Tf6vQCj5c2Dy2Ffv0Sneh6LcNpp7AtfkIAIgg3IQhBq4pV72lprlFsq1YeY/Arv/bZHqEz+1fc8X77wFmaHa2U6ZF1l3r5IZ4vZeuwHc72kZkx3Fdy7nGhrEA1rchplw836zSFds0bTuljY=; 31:t+XFEUaLzNdEVxIDRlVQRXc621FKeNmzazddAM9cMwmuafj2CqGuwi4voI0HW6r0CXSajjPV7z2tB3PCBBXghzqsj9QvqH/kltT6fE1f9TRxuOthzp2C2nLEd/9ZRG69342fMCHZeo6qQypb2kLxs9kzOKnV2q7L8I7B/4AujYLv175j42J3EcbqRxvzS4ojfB1e/yWFDxUH7YiKTtZcPlrBUai6zYcU4wLdvVtSxdK8fnC2cdK78J7k7d8hfa9B X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 20:TYqb/r+9EX7ISkqc5dI3AiF8ML3KTyCO3EaDPXopRZe7RikKsd5ayislizW0aBxUxFbbmULppEpVXPDm56xDYFWJWYB+5uVXg8+u/WI2oxDsWwROfhbIE+Cca4MbAaG1maIWhNjQlu1lQsHV40FydlAYGeiL0bqgDYTGugJiNA4qC/cphm9rS/XWcZ1kALu4IIsaeNnXjnS/jRTilxEF+IVrne5ipdSA2KLbVHE/5Lj7JTWPLSJ00ka24ZgxSAeeG269eg+bh/tEuNEuc/q6PeMPwYmU9U0QdLXqfRrNot/VczirBcxjZcZNmYBrtQvZtc8tnVbP3wF7Nr1tfW2Y/y3ZuVL0Zf8qqogkSNnsTsVsa7flqpCpmhJXz2qMxKNjoRGFcta5vKlhi7ndn6A+9J5BDEeFEBZrOyxGGidvmJMPLaRW1DVWtm9XF5IfzLSLta86wfJoXTiOqPu2stR/s7wnPb+M68f/GvbMbt3FMrF+PqWtr8J2Y01gqzlyBT65 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13018025)(5005006)(8121501046)(13015025)(13017025)(13024025)(13023025)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148); SRVR:BLUPR05MB259; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB259; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 4:WBBjfVlul+MCBZK4RmaGCtw2IQnjtxP/gz4nlG09WqSsxyD3HgEeZfs0Qo0d32ura2Oi+FYJKxTmI7Km0ib5Gq/soqVvsdZTkFItinn1oUKc0FC5xXOHyrMdb+ivWhKlUsAaQFbJRJdyVtnUY4uLKb5AZr//5XTyyj1dcaHFPNQkA1+gBocHzd180EE1goevLWG3Mo3c4rhiKbaajbB2lE5rM1Pw7eeyBaYz/KTr/DO/w0DYmTAXNLSRL2tGq2TIsv7rQnfMzVIPnJqQnasA7sZ0PTe8pJtp9ZowP/LgIBO1qgRjbFW22SzvVVT9JQ83nF7nNU3rS5Y7VrnHfPaHB1jdJlXzmeLoN/s+wME8u3lQAL0Y+qNjAPZFTC2ZGP2KA2mdIVQk6A4fatPGMl5l0xXpSJ1AlX/DqYqkdF4raDT7pioE4zzf6r0XziFnwMQ6OlO+i0gKZfBLMUCkdHcCaYu6EAgfGazQ5HtshCyCT2MUSlRdDz5eNEchF3FSk4aZncCG6c0+u8SokY+TC5XLb0Vzo1UwDdCAV1DaW4CT0jbbk5wmvaqtepsDZzMWSJv5Xqi8TM+P3DSLoKE5lgvDidFRTgLp9i75x7eg+xB+j3LCk5m9k6WyMMPeqlOpwbRlUHWHmdERL1ka5XTTbmPfI0ZSy8v1IYO/py8/Q8eWE4of7MAk0ncEngw8nMQg37GCBFqKY+WWNbZVZFSaaaZ3xQ7TCSCsSFpLpMjCAM7Hhuhg7HyYGyeUBWfVuWg1HEh+QsDKcb8nY8B1J0XZRwTB+USvyoolKNor4K+Nq3ygXhZMR8v4w3ULuz3dnGX09hsCbQFaD3WeuRY04SRywimZcyL7vhnqOmtR8u5G8NURC04RNBA5w9y4DSy0btx710hNMye0qY8iI4WEHBLwmCq3/g== X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB259; 23:e2lvJJLYRm9tC1qr8H53Xvs4GtDzVTVivyDIisBw3e?= =?us-ascii?Q?+9+JXkPk//9s+j9qr8gmKE7INUXKDCk15eKrmGK+Y8JLJwP/k3xCa7elHMd7?= =?us-ascii?Q?7jeMzbw/N/UY677GFTWT4/7Tum/yUKwVnlpwmJK7XGQ1mnX9TOlplESOAclp?= =?us-ascii?Q?geEoAoF4rBvJMRZ8mra94q4OjeesMFY5azg7G6W0R1Tr4UxUOM0cmOKgQdNS?= =?us-ascii?Q?0kDGiTBNDQBpPEQFY0plzn5Y89RUJmN/46hnVby/yOGV2INBpwB2gNI31pi8?= =?us-ascii?Q?AbuQQM03hRejPNtM67AeRlYYerCSgtNgSbzXsf+ruEXWiP//QklL21gMW7ZK?= =?us-ascii?Q?n5pIiFt1yS+M/wcUo6GZ61Lk6tWMWBfvDZz+QYo9pMVaR9UgsNizFAyW/4yw?= =?us-ascii?Q?tk8tdyrhJNZM/aFsHLEay+Dy5LAUUsVHSohu43YIeGs+nL61NZsVpPOMTEiH?= =?us-ascii?Q?qbRDYgvH7ccnIQWEfpT5swk7RQFkieagbMsjJ6JOuJq42zhot5mwzBj8JUzw?= =?us-ascii?Q?HYpnhqSHkVxq/0D4iVYjAwt83BrWNHD39YKOnSlo8D0DX5dFLn3PbPbYPXm4?= =?us-ascii?Q?8cBXVs6jtjDyQ8T0dxO1hPapFSsPpVI0iXJBpbCr6GlcEPBeqFCOqkuKHz2d?= =?us-ascii?Q?kjoJTqfZC48P+W92NaLN4SkklPhu+zImRlIE1FR7srVra6J5aVsP8hvvkfuc?= =?us-ascii?Q?uFjdrIK8mKCEBXX5+rHZifP1VmLSqftga9LBCWcOSBVHHI4TS4G/Z/CTHXV9?= =?us-ascii?Q?GcLh70L1QuwIdqeqONedaY3Q59queAcse+rmmZK/T6KWngsq6lD6MoQg9VbK?= =?us-ascii?Q?T0naJURddM4BZCcWzlkrI0Qw8IQpfS8lXte2zzQ2+yYs5i4neaoAIVg8Oh+k?= =?us-ascii?Q?KW2zyiLjUn4m148yzpcXQOOsksi3foyWxqt7QMEp7BNSdxvGSJMzeBS4ZSvt?= =?us-ascii?Q?3AWok5yWKHW8QWoaBw52mD0gYvqvbyoCrvkEff1XLyJhglEZRe7JVb7qOA7I?= =?us-ascii?Q?iTarG6KjAO6/3dkNr4ww2mps1wnH+Xn5+3J6bU1E8l3W/6bkEoC6aWyYITIn?= =?us-ascii?Q?cUu5500BqxvMFMuua8KhtOguc3LOzlKIiX286C1rVJpJNWl4a+USBG5FcTQi?= =?us-ascii?Q?E9ADIIUmxHeoTtDmOuyIXzq9kLefrq27ot9ksMQO8RvmuGwM90kzQ0H+vXF4?= =?us-ascii?Q?1XDeQnnWbQPMxLzSxR4ceUdLyxY7pV8OQrdR5yPVXIQmElyd2gZBjy43CVkk?= =?us-ascii?Q?sogO5UzCmZAJeYXdo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 6:t6sIl6RJxA3p0xqmRsrtbpdqhtXcLoCbgTjgsaVjO3g4lJCUMonK8MTXwJmlrmg0m6/clSmx0e8VFyZ+92Jkrr5daUFwlTfgncj6oqqXVW/rMswaWH9X4nWZ+DYTX69GNiH+IU3XAAx+y4Zudv++KJ9FarE8rvpp9TUyhTGfPVWYUG5BGnCm/DURcXMTtSFcodXx4FOQS650C9u+C+8VDRbuSrjA8oRrEybh5q+7Hg4C98FGVvJcNzZemh36om3FfdfuvjgXtLUm7jz+cDz2h5Hz2TNkuZ+c5uG1Q9/qoNxeorT4OwVu3NBtkNzpOZzjYfbVTpXf9hqO/y+ZpI0ETSn3TLlrraKLLZGz84uXRJ0JZUXg+pO4KETpNb2ma1LybT1CYJtzYLMHd46hGg3c51WUHuq0H8KxFVpzeiWATObRPHsjWJ5S6LmX0Tdhraoq5KTKnFS2dbdddR76g8KT8z/WONKmKE8UHEz7GRuKLYuknMdV8Hu9MJh6QdKkEwPwm+cqS0pc9L+8cQZESZ6tLkn5c40YNOWdNIh9WsaRqJc=; 5:uqT6rM5uXT+RdiTX2TIFzocovFurSFn/cLOgiIGCbU+HgEZO0R3HDu3mawXsTH08UqNIWaWsH7J/CpEJx39olyez98VHZXS1w9+/0CcsIxXFGlNp6bEBL1xfib3WEFeusoj+lr6OSuCEcoA55HI5lw==; 24:1Qgz7qOg43nuUrJRuzMFO4qVflagGp4HQjBE5qj+6y6fHovqVPb8/wQMmyh17dIL9/4tNZgze233fyO8tZ67ddKfXLchaEZXB7h+OPTZsvY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 7:prX8bieCj0JgPMJdHOYFmsU3te3Gf1IdgYYcpc1G06AFFKYhbkR3aCnSLpujQA4EYtXaz+cr2rO3yns2M7IRDaEgd7RLQqhUan3OuMqDiIZ6icTzORU78zKgQxRJUCRUED5BOiSTOfSzRFdufZInzgxDhrY1ddMAKlHgjBXT4ef5AAV/nKdCy75HMPdKuTI6uJmWRtVPXsvVpCYd7Lm+IODRkz6EJMrm2qzjLgoFCMoT3TTaF1SYPJOgsIhEt761zNMRPfZfzu8nYAitUoq85DTcpC1OguGQtkWjOqRCbma6uNEUUz18hu90Grl8AAnrDY/wA7Y7fnqFKj/HG5GUfQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 14:39:19.4941 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB259 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 14:46:09 -0000 Hi Setphan, I think I will use this text... To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: Trim all leading zero-bytes of X. If X is all zero-bytes, then the key exchange must fail. If the high bit of X is set, the mpint format requires a zero byte to be prepended. The length of the encoded K may not be the same as the original length of X due to trimming or prepending a zero-byte as needed for "mpint" format. I will also add your suggested pseudo code. Thank you, -- Mark From ronf@timeheart.net Wed May 10 19: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 4514312EB2A for ; Wed, 10 May 2017 19:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlYgwVFDVqpu for ; Wed, 10 May 2017 19:49:32 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 037B01296C9 for ; Wed, 10 May 2017 19:49:31 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e193so6681052pfh.0 for ; Wed, 10 May 2017 19:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=UsHslBSMnOSAce3knbV/TUFamDyOX5vmEdphL55JKcOQNB4QYKGmd6NwE37N9J9QGe EwRWNdWTP/lpkPpb9g0DP9yWHRqqY8/uHo7LNVja0aoSr65Gw7bjV8useYRrwpmmAWUd SAMGsxoNrr9YYQnyUC72rfeSl9EUmgJnkUOOw= 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=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=SyzIWlr/fwYO2Yk4jBeXnkWBbXfydkAB1PKOOMZwhnTXiAPiDp3X9RXBZIKxaY5wBx ZiY3UtUYTbirKOX9BfdRE5VhoE8g7htIyH/QZPkAG6+CMoRQba9OTR0pKfY8AuDjXgvV j1cCJTpq4xoNXc1sHH3JAlTbRZ7XcB5nnsDwYdXdUqfBD0VPaN+Ul8ck3OfAHfSYSJ2D aAYl9njvL7iEkUi3UMYGdv9gc7oAvOLLCoBSRETlUDn2ACqdUvFLyHsfmEwNYvoLad7l GcrqsCHe2jv/64AD3UGxH55UH6avpMLqJbiPTb6NOmfUVD5MBboBpInEsFvYyeTdhz4N Gjvw== X-Gm-Message-State: AODbwcDA52y89gacYgk7sE+6nqYWXj5fCULMHitqxRJ421fKz57YBcvy tmL37gEo+Jobng== X-Received: by 10.84.130.7 with SMTP id 7mr12474829plc.35.1494470971492; Wed, 10 May 2017 19:49:31 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id z68sm416169pgz.14.2017.05.10.19.49.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 19:49:30 -0700 (PDT) From: Ron Frederick Message-Id: <0BC6F061-CBFB-4935-9C00-42CB1741543D@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 19:49:29 -0700 In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Cc: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: Mark Baushke References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-Mailman-Approved-At: Thu, 11 May 2017 07:50:29 -0700 Subject: Re: [Curdle] ssh-ed25519 implementations 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, 11 May 2017 02:50:39 -0000 --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke wrote: > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: >=20 > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + >=20 > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. >=20 > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. >=20 > Please reply to curdle@ietf.org with your opinions. I have implemented for ssh-ed25519 public keys and certificates in = AsyncSSH, and my implementation currently uses opaque byte strings taken = from the implementation of curve25519 in libsodium when encoding public = and private keys. These byte strings are encoded as SSH =E2=80=98string=E2= =80=99 values (4-byte big-endian string length followed by an array of = bytes of that length). The public key is a single string value and the = private key is the concatenation of two string values (public key = followed by private key, each with its own preceding 4-byte length = value). This implementation interoperates with OpenSSH. More details can be found in the Internet Draft at: https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00 = This refers to: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03 = I have also implemented curve25519-sha256@libssh.org = key exchange as documented at: = https://git.libssh.org/projects/libssh.git/plain/doc/curve25519-sha256@lib= ssh.org.txt = OpenSSH also implements this, and makes it available under both this = name and more recently as just =E2=80=9Ccurve25519-sha256=E2=80=9D. Here, the public key values exchanged in messages like KEX_ECDH_INIT and = KEX_ECDH_REPLY are opaque byte strings similar to the above. As = discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 = , the final = computed shared secret value is converted to an integer by taking the = 32-byte point obtained by scalar multiplication and treating the bytes = as a bigendian (network byte order) value, but this value is never = directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpint" = encoding ever applies to it. The only values on the wire are the public = keys and signature values, all of which are encoded as strings. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke <mdb@juniper.net> = wrote:
Eric = Rescorla <ekr@rtfm.com> has brought to my attention that in
https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= it is
currently specifying the SSH encoding of secrets on = the wire using the
mpint process as described in section 5 = of [RFC4251] while RFC 7748
describes using a = little-endian format:

 GF(2^448 - = 2^224 - 1) and are encoded as an array of bytes, u,
=  in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + = ... +

This seems to be what is being = implemeneted for
curve25519-sha256@libssh.org, so I should make
an explicit note of this in the draft.

However, I am unaware of any curve448-sha512 implementations = at
present and would like consensus that it should also = follow the mpint
method rather than the RFC 7748 = method.

Please reply to curdle@ietf.org with your = opinions.
I have implemented for ssh-ed25519 public keys and = certificates in AsyncSSH, and my implementation currently uses opaque = byte strings taken from the implementation of curve25519 in libsodium = when encoding public and private keys. These byte strings are encoded as = SSH =E2=80=98string=E2=80=99 values (4-byte big-endian string length = followed by an array of bytes of that length). The public key is a = single string value and the private key is the concatenation of two = string values (public key followed by private key, each with its own = preceding 4-byte length value). This implementation interoperates with = OpenSSH.

More = details can be found in the Internet Draft at:

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00

This refers = to:

https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03

I have also = implemented curve25519-sha256@libssh.org key exchange as = documented at:

https://git.libssh.org/projects/libssh.git/plain/doc/curve25519= -sha256@libssh.org.txt

OpenSSH also implements this, and makes it available under = both this name and more recently as just = =E2=80=9Ccurve25519-sha256=E2=80=9D.

Here, the public key values exchanged = in messages like KEX_ECDH_INIT and KEX_ECDH_REPLY are opaque byte = strings similar to the above. As discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= , the final computed shared secret value is converted to an integer by = taking the 32-byte point obtained by scalar multiplication and treating = the bytes as a bigendian (network byte order) value, but this value is = never directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpin= t" encoding ever applies to it. The only values on the wire are the = public keys and signature values, all of which are encoded as = strings.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA-- From nobody Thu May 11 09:21:33 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F200A130889 for ; Thu, 11 May 2017 09:21:31 -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 IKZW_x0ioqDx for ; Thu, 11 May 2017 09:21: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 CD340127B5A for ; Thu, 11 May 2017 09:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 10CA0300564 for ; Thu, 11 May 2017 12:15:48 -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 9DqnFz-nlwue for ; Thu, 11 May 2017 12:15:44 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C701300295; Thu, 11 May 2017 12:15:44 -0400 (EDT) From: Russ Housley Message-Id: <597A9F82-7861-4680-ABFE-ADA1E26C79EE@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0BA7EFFA-8B01-4322-A477-EC188ED1DD92" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 12:15:47 -0400 In-Reply-To: Cc: Jim Schaad , curdle To: Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Thu, 11 May 2017 16:21:32 -0000 --Apple-Mail=_0BA7EFFA-8B01-4322-A477-EC188ED1DD92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To make it flow with the text that is already there, I suggest: X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. Conforming implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value, and abort if so, as described in Section 6 of [CURVES]. If an alternative implementation of these elliptic curves is employed, then the additional checks specified in Section 7 of [CURVES] SHOULD be performed. Russ > On May 10, 2017, at 6:06 PM, Eric Rescorla wrote: >=20 > I apologize but I just took a look at the language around invalid = points. I would suggest > you use the same language as TLS here: >=20 > For X25519 and X448, implementations SHOULD use the approach > specified in [RFC7748] to calculate the Diffie-Hellman shared = secret. > Implementations MUST check whether the computed Diffie-Hellman = shared > secret is the all-zero value and abort if so, as described in > Section 6 of [RFC7748]. If implementers use an alternative > implementation of these elliptic curves, they SHOULD perform the > additional checks specified in Section 7 of [RFC7748]. >=20 > LMK what you think. >=20 > Best, > -Ekr >=20 >=20 > On Wed, May 10, 2017 at 6:50 AM, Russ Housley > wrote: > Yes, that works for me. I=E2=80=99ll post an updated I-D later today. >=20 > Russ >=20 >=20 >> On May 9, 2017, at 7:59 PM, Eric Rescorla > wrote: >>=20 >> I guess I would focus on the uniqueness of the input, because the = output's uniqueness is largely a function of: >>=20 >> 1. Input uniqueness >> 2. The number of discrete inputs. >>=20 >> So, I think I would say: >>=20 >> "it MUST be selected in a manner that ensures it is unique with high = probability" >>=20 >> -Ekr >>=20 >>=20 >>=20 >> On Tue, May 9, 2017 at 3:35 PM, Russ Housley > wrote: >>=20 >>> On May 9, 2017, at 5:16 PM, Eric Rescorla > wrote: >>>=20 >>>=20 >>> On Tue, May 9, 2017 at 1:25 PM, Russ Housley > wrote: >>>>>>> > The ECC-CMS-SharedInfo entityUInfo field optionally = contains >>>>>>> > additional keying material supplied by the sending agent. = Note that >>>>>>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>>>>>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>>>>>> > the ukm is placed in the entityUInfo field. The ukm value = need not >>>>>>> > be longer than the key-encryption key that will be produced = by the >>>>>>> > KDF. >>>>>>> > >>>>>>> > Need not? Please clarify what the purpose is here. It seems = like >>>>>>> > it's to generate a unique KEK. In that case, the security = bounds >>>>>>> > are what, uniqueness? >>>>>>>=20 >>>>>>> I suggest this wording: >>>>>>>=20 >>>>>>> =E2=80=A6 There is no security benefit to using a ukm value = that is >>>>>>> longer than the key-encryption key that will be produced by >>>>>>> the KDF. >>>>>> =20 >>>>>> Hmm... I believe that this statement is true, but it also seems = to be >>>>>> incomplete. I may be reasoning about this incorrectly, but it = seems >>>>>> to me that the minimal security requirement is that the UKM be >>>>>> unique, but that can be achieved with a value much smaller than >>>>>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>>>>> then you would still be OK with a randomly-generated 128-bit >>>>>> UKM. And if we're concerned about random collisions, then the >>>>>> usefulness bound is actually min(|KEK|, |hash compression = function size|). >>>>> =20 >>>>> Yes. The umm value needs to be different for each invocation of = the KDF, otherwise it does not provide the assurance that different = keying material will be produced. Of course, an implementation will = generate the umm value using random number generator, not track the = values that are used. Several years ago, there was a discussion about = the size of the ukm needed. Some people were suggesting crazy large = values, and the point was made that anything beyond the SIZEOF(KEK) did = not improve security. >>>>> =20 >>>>> Are you asking for a sentence saying that the ukm, if present, = MUST be at least 128 bits? >>>>> =20 >>>>> [JLS] I would disagree that the value has to be random, a counter = will work as well. (An encrypted counter is better.) I not be happy = with a fixed size requirement on this easier. There is no reason to = make such a requirement that I can think of. A 64-bit counter is just = as rational. It might make more sense to change this statement into = something along the lines of=20 >>>>> =20 >>>>> * Any pair of static keys MUST NOT be used more times than the = size of the key. I.e. if 128-bit KEKs may be used, then there is a = 2^128 limit on the number of times the key pair can be used. >>>>> * The size of the KEK is normally not longer than the length of = the resulting KEK as that is the limit of unique values that can be = generated in any event. >>>> =20 >>>> Section 2 already says that the ephemeral key MUST be used for only = one message. Thus, a UKM is not really needed. However, the CMS = requires support for a UKM if the sender include it. For this reason, = the document says how to handle it in the KDF if it is present. >>>> =20 >>>> You are correct that a counter, encrypted counter, or random value = will work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. >>>> =20 >>>> The text already says that there is no security reason for a UKM = value that is longer than the KEK. I think that EKR is asking for = guidance on the minimum size too. >>>> =20 >>>> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum = size would be one bit. Although this is not legal from an ASN.1 = standpoint =E2=80=93 so the minimum would be one byte.=20 >>>> =20 >>>> A single byte with all bits zero and two bytes with all bits zero = are different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 >>>=20 >>> I suggest: >>>=20 >>> The ECC-CMS-SharedInfo entityUInfo field optionally contains >>> additional keying material supplied by the sending agent. Note = that >>> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>> SEQUENCE that includes the ukm field. If the ukm field is = present, >>> the ukm is placed in the entityUInfo field. When present, the = ukm >>> ensures that a different key-encryption key is generated, even = when >>> the originator ephemeral private key is improperly used more than >>> once. Therefore, if the ukm field is present, it MUST be = selected in >>> a manner that ensures a unique KDF output; >>>=20 >>> Is this actually possible? The KDF is basically a PRF, so there is = some >>> chance that 0*128 and 1*128 produce the same output. >>=20 >> s/ensure/will with very high probability produce/ >>=20 >> Russ >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_0BA7EFFA-8B01-4322-A477-EC188ED1DD92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To make it flow with the text that is already there, I = suggest:

   X25519 is described in Section 6.1 of [CURVES], = and X448 is described
   in Section 6.2 = of [CURVES].  Conforming implementations MUST check
   whether the computed Diffie-Hellman shared = secret is the all-zero
   value, and = abort if so, as described in Section 6 of [CURVES].  If = an
   alternative implementation of these = elliptic curves is employed, then
   the = additional checks specified in Section 7 of [CURVES] SHOULD be
   performed.

Russ


On May 10, 2017, at 6:06 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

I apologize but I just took a look at the language around = invalid points. I would suggest
you use the same language = as TLS here:

   For X25519 and X448, = implementations SHOULD use the approach
  =  specified in [RFC7748] to calculate the Diffie-Hellman shared = secret.
   Implementations MUST check = whether the computed Diffie-Hellman shared
  =  secret is the all-zero value and abort if so, as described = in
   Section 6 of [RFC7748].  If = implementers use an alternative
  =  implementation of these elliptic curves, they SHOULD perform = the
   additional checks specified in = Section 7 of [RFC7748].

LMK what you think.

Best,
-Ekr


On Wed, = May 10, 2017 at 6:50 AM, Russ Housley <housley@vigilsec.com> wrote:
Yes, that works for me.  = I=E2=80=99ll post an updated I-D later today.

Russ


On May = 9, 2017, at 7:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

I guess I would focus on the = uniqueness of the input, because the output's uniqueness is largely a = function of:

1. = Input uniqueness
2. The number of discrete = inputs.

So, I = think I would say:

"it MUST be = selected in a = manner that ensures it is unique with high probability"

-Ekr



On Tue, May 9, 2017 at 3:35 PM, = Russ Housley <housley@vigilsec.com> wrote:

On May = 9, 2017, at 5:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, = May 9, 2017 at 1:25 PM, Russ Housley <housley@vigilsec.com> wrote:
>    The ECC-CMS-SharedInfo entityUInfo field = optionally contains
>    additional keying = material supplied by the sending agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that = includes the ukm field.  If the ukm field is present,
>    the ukm is placed in the entityUInfo = field.  The ukm value need not
>    be = longer than the key-encryption key that will be produced by the
>    KDF.
>
> = Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the = security bounds
> are what, uniqueness?
I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that = will be produced by
   the KDF.
 
Hmm... = I believe that this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me = that the minimal security requirement is that the UKM be
unique,= but that can be achieved with a value much smaller than
the = KEK. For instance, it seems like if you have a 256-bit KEK,
then = you would still be OK with a randomly-generated 128-bit
UKM. = And if we're concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression = function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are = you asking for a sentence saying that the ukm, if present, MUST be at = least 128 bits?
 
[JLS] I would disagree that = the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of 
 
* Any pair of static keys MUST = NOT be used more times than the size of the key.  I.e. if 128-bit = KEKs may be used, then there is a 2^128 limit on the number of times the = key pair can be used.
* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any event.
 
Section= 2 already says that the ephemeral key MUST be used for only one = message.  Thus, a UKM is not really needed.  However, the CMS = requires support for a UKM if the sender include it.  For this = reason, the document says how to handle it in the KDF if it is = present.
 
You = are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages.  The text does not limit the choices in any way.
 
The = text already says that there is no security reason for a UKM value that = is longer than the KEK.  I think that EKR is asking for guidance on = the minimum size too.
 
[JLS] It=E2=80=99= s kind of a stupid thing to do, but the minimum size would be one = bit.  Although this is not legal from an ASN.1 standpoint =E2=80=93 = so the minimum would be one byte. 
 
A single byte with all bits = zero and two bytes with all bits zero are different ukm values because = of the way that they are used in the ECC-CMS-SharedInfo structure.  = Note that this would not be the case if the ukm value was only used as a = salt value to HKDF.  I do not see any reason to specify a minimum = length of this value.  The only thing that is required is = uniqueness, EKR is correct about saying this. 

I = suggest:

   The ECC-CMS-SharedInfo = entityUInfo field optionally contains
  =  additional keying material supplied by the sending agent.  = Note that
   [CMS] requires = implementations to accept a KeyAgreeRecipientInfo
   SEQUENCE that includes the ukm field.  If = the ukm field is present,
   the = ukm is placed in the entityUInfo field.  When present, the = ukm
   ensures that a different = key-encryption key is generated, even when
  =  the originator ephemeral private key is improperly used more = than
   once.  Therefore, if the ukm = field is present, it MUST be selected in
  =  a manner that ensures a unique KDF = output;

Is this actually possible? The KDF is = basically a PRF, so there is some
chance that 0*128 = and 1*128 produce the same = output.

s/ensure/will with very = high probability produce/

Russ





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

= --Apple-Mail=_0BA7EFFA-8B01-4322-A477-EC188ED1DD92-- From nobody Thu May 11 11:19:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F7112EB8F for ; Thu, 11 May 2017 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNKHtrZgPP9f for ; Thu, 11 May 2017 11:19:39 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4858512EC00 for ; Thu, 11 May 2017 11:13:51 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l14so414601ywk.1 for ; Thu, 11 May 2017 11:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n4IpIP3QitHro6W/7j3FVugT9+sbxLfZK6MNs3yyEQg=; b=nMlLg59q0H4JXRABvevqksGJvc1HMDm1lOKE6UQQYnvApIoK00ry5BVo5KnTh2ZVW6 puAr0ZxBr/j8VvbhXty74YCE1ZoHy4OhyIEVxwtewt3Qk2+15GXw0QwAbVfiJnEJSQ3m 4GPXzk5sajkbIk+Ep1/gdWPknhiJtZwgaqJF8oc5EB+q9ZKjloIoJtmm3Awby6rKfGAW NWQ6mkLt9tgflaKpIrTDqYGCCkyimKOFwZZdOg0JOukb9J1YuZZB49Q12Y+6ti0tgGTZ +FFKp1iwvX6HgA47BUf2Zy8JKKSaMghy77pmQS0b6nVF/d6lR10S18odqhSQfCBCQJlf UknQ== 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=n4IpIP3QitHro6W/7j3FVugT9+sbxLfZK6MNs3yyEQg=; b=RPTzzl6EG8pEo+VxVYjC6G6tTsnf03+Hz/zjPu89dLHnAfQzfWnNWavD5aPa1BTTE9 fBdPtLhJAj2wZFcRcP4TZCsBHOFHdJqCX14b2BM3qo37dDHdl2/Pd/poAHWb5BI0QQID z3mMhyzzGleILtYRLPlQhIlKynKcbEtFTGYuamneibbeP1y2x28Mn1Y0z17GBMRKQBTO EB0vQfZtWt+tjbQOwdXd42iLkE1bZFvGBR8gCFDj3FyVSJVBdNZ+jEt9/CuFtosBkD9O 3qKKS1PZFLDp0L0DswCF4lKoXft9tWSoe+ZN1WVd4HDZCP94leGYIWmZMLP4s43Apg3I whtg== X-Gm-Message-State: AODbwcCo6RGyVJb/zzx3/QaTijks0OtGEgwiAqGComphRqY/h+Hkjx3e IWquZrXE/X2SdzrBlRb9zWRk5qn3Rg== X-Received: by 10.13.245.2 with SMTP id e2mr107484ywf.270.1494526430479; Thu, 11 May 2017 11:13:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Thu, 11 May 2017 11:13:09 -0700 (PDT) In-Reply-To: <597A9F82-7861-4680-ABFE-ADA1E26C79EE@vigilsec.com> References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> <597A9F82-7861-4680-ABFE-ADA1E26C79EE@vigilsec.com> From: Eric Rescorla Date: Thu, 11 May 2017 11:13:09 -0700 Message-ID: To: Russ Housley Cc: Jim Schaad , curdle Content-Type: multipart/alternative; boundary=94eb2c08763aff2559054f438ca7 Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Thu, 11 May 2017 18:19:42 -0000 --94eb2c08763aff2559054f438ca7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nit, I think you should specify alternative to what. If an alternative implementation of these elliptic curves to that documented in [RFC7748 Section 6] is employed, then the additional checks specified in Section 7 of [CURVES] SHOULD be performed. On Thu, May 11, 2017 at 9:15 AM, Russ Housley wrote: > To make it flow with the text that is already there, I suggest: > > X25519 is described in Section 6.1 of [CURVES], and X448 is described > in Section 6.2 of [CURVES]. Conforming implementations MUST check > whether the computed Diffie-Hellman shared secret is the all-zero > value, and abort if so, as described in Section 6 of [CURVES]. If an > alternative implementation of these elliptic curves is employed, then > the additional checks specified in Section 7 of [CURVES] SHOULD be > performed. > > Russ > > > On May 10, 2017, at 6:06 PM, Eric Rescorla wrote: > > I apologize but I just took a look at the language around invalid points. > I would suggest > you use the same language as TLS here: > > For X25519 and X448, implementations SHOULD use the approach > specified in [RFC7748] to calculate the Diffie-Hellman shared secret. > Implementations MUST check whether the computed Diffie-Hellman shared > secret is the all-zero value and abort if so, as described in > Section 6 of [RFC7748]. If implementers use an alternative > implementation of these elliptic curves, they SHOULD perform the > additional checks specified in Section 7 of [RFC7748]. > > LMK what you think. > > Best, > -Ekr > > > On Wed, May 10, 2017 at 6:50 AM, Russ Housley > wrote: > >> Yes, that works for me. I=E2=80=99ll post an updated I-D later today. >> >> Russ >> >> >> On May 9, 2017, at 7:59 PM, Eric Rescorla wrote: >> >> I guess I would focus on the uniqueness of the input, because the >> output's uniqueness is largely a function of: >> >> 1. Input uniqueness >> 2. The number of discrete inputs. >> >> So, I think I would say: >> >> "it MUST be selected in a manner that ensures it is unique with high >> probability" >> >> -Ekr >> >> >> >> On Tue, May 9, 2017 at 3:35 PM, Russ Housley >> wrote: >> >>> >>> On May 9, 2017, at 5:16 PM, Eric Rescorla wrote: >>> >>> >>> On Tue, May 9, 2017 at 1:25 PM, Russ Housley >>> wrote: >>> >>>> > The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>> > additional keying material supplied by the sending agent. Note >>>> that >>>> > [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>>> > SEQUENCE that includes the ukm field. If the ukm field is presen= t, >>>> > the ukm is placed in the entityUInfo field. The ukm value need n= ot >>>> > be longer than the key-encryption key that will be produced by th= e >>>> > KDF. >>>> > >>>> > Need not? Please clarify what the purpose is here. It seems like >>>> > it's to generate a unique KEK. In that case, the security bounds >>>> > are what, uniqueness? >>>> >>>> I suggest this wording: >>>> >>>> =E2=80=A6 There is no security benefit to using a ukm value that is >>>> longer than the key-encryption key that will be produced by >>>> the KDF. >>>> >>>> >>>> Hmm... I believe that this statement is true, but it also seems to be >>>> incomplete. I may be reasoning about this incorrectly, but it seems >>>> to me that the minimal security requirement is that the UKM be >>>> unique, but that can be achieved with a value much smaller than >>>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>>> then you would still be OK with a randomly-generated 128-bit >>>> UKM. And if we're concerned about random collisions, then the >>>> usefulness bound is actually min(|KEK|, |hash compression function >>>> size|). >>>> >>>> >>>> Yes. The umm value needs to be different for each invocation of the >>>> KDF, otherwise it does not provide the assurance that different keying >>>> material will be produced. Of course, an implementation will generate= the >>>> umm value using random number generator, not track the values that are >>>> used. Several years ago, there was a discussion about the size of the= ukm >>>> needed. Some people were suggesting crazy large values, and the point= was >>>> made that anything beyond the SIZEOF(KEK) did not improve security. >>>> >>>> Are you asking for a sentence saying that the ukm, if present, MUST be >>>> at least 128 bits? >>>> >>>> [JLS] I would disagree that the value has to be random, a counter will >>>> work as well. (An encrypted counter is better.) I not be happy with = a >>>> fixed size requirement on this easier. There is no reason to make suc= h a >>>> requirement that I can think of. A 64-bit counter is just as rational= . It >>>> might make more sense to change this statement into something along th= e >>>> lines of >>>> >>>> * Any pair of static keys MUST NOT be used more times than the size of >>>> the key. I.e. if 128-bit KEKs may be used, then there is a 2^128 limi= t on >>>> the number of times the key pair can be used. >>>> * The size of the KEK is normally not longer than the length of the >>>> resulting KEK as that is the limit of unique values that can be genera= ted >>>> in any event. >>>> >>>> >>>> Section 2 already says that the ephemeral key MUST be used for only on= e >>>> message. Thus, a UKM is not really needed. However, the CMS requires >>>> support for a UKM if the sender include it. For this reason, the docu= ment >>>> says how to handle it in the KDF if it is present. >>>> >>>> You are correct that a counter, encrypted counter, or random value wil= l >>>> work, even if the originator uses the same ephemeral key for many >>>> messages. The text does not limit the choices in any way. >>>> >>>> The text already says that there is no security reason for a UKM value >>>> that is longer than the KEK. I think that EKR is asking for guidance = on >>>> the minimum size too. >>>> >>>> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum size = would be >>>> one bit. Although this is not legal from an ASN.1 standpoint =E2=80= =93 so the >>>> minimum would be one byte. >>>> >>>> A single byte with all bits zero and two bytes with all bits zero are >>>> different ukm values because of the way that they are used in the >>>> ECC-CMS-SharedInfo structure. Note that this would not be the case if= the >>>> ukm value was only used as a salt value to HKDF. I do not see any rea= son >>>> to specify a minimum length of this value. The only thing that is req= uired >>>> is uniqueness, EKR is correct about saying this. >>>> >>>> >>>> I suggest: >>>> >>>> The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>> additional keying material supplied by the sending agent. Note tha= t >>>> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>>> SEQUENCE that includes the ukm field. If the ukm field is present, >>>> the ukm is placed in the entityUInfo field. When present, the ukm >>>> ensures that a different key-encryption key is generated, even when >>>> the originator ephemeral private key is improperly used more than >>>> once. Therefore, if the ukm field is present, it MUST be selected = in >>>> a manner that ensures a unique KDF output; >>>> >>> >>> Is this actually possible? The KDF is basically a PRF, so there is some >>> chance that 0*128 and 1*128 produce the same output. >>> >>> >>> s/ensure/will with very high probability produce/ >>> >>> Russ >>> >>> >>> >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > --94eb2c08763aff2559054f438ca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nit, I think you should specify alternative to what.
<= br>
=C2=A0 If an
=C2=A0 =C2=A0alternative implementation of these elliptic cu= rves to that documented
=C2=A0 =C2=A0i= n [RFC7748 Section 6] is employed, then
=C2=A0 =C2=A0the additional checks specified in Section 7 of [CURVES] SHO= ULD be
=C2=A0 =C2=A0performed.

O= n Thu, May 11, 2017 at 9:15 AM, Russ Housley <housley@vigilsec.com= > wrote:
To make it flow with the text that is already there, I sugges= t:

=C2=A0 =C2=A0X25519 is describe= d in Section 6.1 of [CURVES], and X448 is described
=C2=A0= =C2=A0in Section 6.2 of [CURVES].=C2=A0 Conforming implementations MUST ch= eck
=C2=A0 =C2=A0whether the computed Diffie-Hel= lman shared secret is the all-zero
=C2=A0 =C2=A0value, and= abort if so, as described in Section 6 of [CURVES].=C2=A0 If an
= =C2=A0 =C2=A0alternative implementation of these elliptic curves is employe= d, then
=C2=A0 =C2=A0the additional checks specified in Section 7= of [CURVES] SHOULD be
=C2=A0 =C2=A0performed.

Russ


On May 10, 2017, at 6:06 PM, Eric Rescorla &= lt;ekr@rtfm.com> w= rote:

I apologize but I jus= t took a look at the language around invalid points. I would suggest
yo= u use the same language as TLS here:

=C2=A0 = =C2=A0For X25519 and X448, implementations SHOULD use the approach
=C2=A0 =C2=A0specified in [RFC7748] to calculate the Diffie-Hellman share= d secret.
=C2=A0 =C2=A0Implementations MUST check whether the com= puted Diffie-Hellman shared
=C2=A0 =C2=A0secret is the all-zero v= alue and abort if so, as described in
=C2=A0 =C2=A0Section 6 of [= RFC7748].=C2=A0 If implementers use an alternative
=C2=A0 =C2=A0i= mplementation of these elliptic curves, they SHOULD perform the
= =C2=A0 =C2=A0additional checks specified in Section 7 of [RFC7748].

LMK what you think.

Best,<= /div>
-Ekr


On Wed, May 10, 2017 at 6:50 AM, Russ Housley <= housley@vigilsec.com> wrote:
Yes, that works for me.=C2=A0 I=E2=80= =99ll post an updated I-D later today.

Russ
=


On May 9, 2017, at 7:59 PM, Eric Rescorla <= ekr@rtfm.com> wrot= e:

I guess I would focus on the uniquenes= s of the input, because the output's uniqueness is largely a function o= f:

1. Input uniqueness
2. The number of discre= te inputs.

So, I think I would say:

=
"it MUST be selected in=C2=A0a manner that ensures it is uniq= ue with high probability"

-Ekr



On Tue, May 9= , 2017 at 3:35 PM, Russ Housley <housley@vigilsec.com> wr= ote:
=

<= blockquote type=3D"cite">
On May 9, 2017, at 5:16 PM, Eric Rescorla <= ;ekr@rtfm.com> wro= te:


On Tue, May 9, 2017 at 1:25 PM, = Russ Housley <housley@vigilsec.com> wrote:
<= blockquote style=3D"margin-top:5pt;margin-bottom:5pt" type=3D"cite">
>=C2=A0 =C2=A0 The ECC-= CMS-SharedInfo entityUInfo field optionally contains
>=C2=A0 =C2=A0 a= dditional keying material supplied by the sending agent.=C2=A0 Note that>=C2=A0 =C2=A0 [CMS] requires implementations to accept a KeyAgreeRecip= ientInfo
>=C2=A0 =C2=A0 SEQUENCE that includes the ukm field.=C2=A0 I= f the ukm field is present,
>=C2=A0 =C2=A0 the ukm is placed in the e= ntityUInfo field.=C2=A0 The ukm value need not
>=C2=A0 =C2=A0 be long= er than the key-encryption key that will be produced by the
>=C2=A0 = =C2=A0 KDF.
>
> Need not? Please clarify what the purpose is he= re. It seems like
> it's to generate a unique KEK. In that case, = the security bounds
> are what, uniqueness?

I suggest this wor= ding:

=C2=A0 =C2=A0=E2=80=A6 There is no security benefit to using a= ukm value that is
=C2=A0 =C2=A0longer than the key-encryption key that = will be produced by
=C2=A0 =C2=A0the KDF.
=C2=A0
Hmm... I believe that this statement is true, but it also seems = to be
incomplete. I may = be reasoning about this incorrectly, but it seems
=
to me that the minimal security requirement is th= at the UKM be
unique, bu= t that can be achieved with a value much smaller than
the KEK. For instance, it seems like if you h= ave a 256-bit KEK,
then = you would still be OK with a randomly-generated 128-bit
=
UKM. And if we're concerned about rando= m collisions, then the
= usefulness bound is actually min(|KEK|, |hash compression function size|).<= u>
=C2=A0
Yes. The umm va= lue needs to be different for each invocation of the KDF, otherwise it does= not provide the assurance that different keying material will be produced.= =C2=A0 Of course, an implementation will generate the umm value using rando= m number generator, not track the values that are used.=C2=A0 Several years= ago, there was a discussion about the size of the ukm needed.=C2=A0 Some p= eople were suggesting crazy large values, and the point was made that anyth= ing beyond the SIZEOF(KEK) did not improve security.
=C2=A0
Are you asking for a sentence saying that the ukm, if present, = MUST be at least 128 bits?
=C2=A0
[JLS] I would disagree that the value has to be rand= om, a counter will work as well.=C2=A0 (An encrypted counter is better.)=C2= =A0 I not be happy with a fixed size requirement on this easier.=C2=A0 Ther= e is no reason to make such a requirement that I can think of.=C2=A0 A 64-b= it counter is just as rational.=C2=A0 It might make more sense to change th= is statement into something along the lines of=C2=A0
=C2=A0
* Any pair of st= atic keys MUST NOT be used more times than the size of the key.=C2=A0 I.e. = if 128-bit KEKs may be used, then there is a 2^128 limit on the number of t= imes the key pair can be used.
* The size of the KEK is normally n= ot longer than the length of the resulting KEK as that is the limit of uniq= ue values that can be generated in any event.
=C2=A0
=
Section 2 already says that the ephemeral key MUST be used for on= ly one message.=C2=A0 Thus, a UKM is not really needed.=C2=A0 However, the = CMS requires support for a UKM if the sender include it.=C2=A0 For this rea= son, the document says how to handle it in the KDF if it is present.=
=C2=A0
You are correct that a counter, encrypted counter, or random value wi= ll work, even if the originator uses the same ephemeral key for many messag= es.=C2=A0 The text does not limit the choices in any way.
=C2=A0
The t= ext already says that there is no security reason for a UKM value that is l= onger than the KEK.=C2=A0 I think that EKR is asking for guidance on the mi= nimum size too.
=C2=A0
[JLS] It=E2=80=99s kind of a stu= pid thing to do, but the minimum size would be one bit.=C2=A0 Although this= is not legal from an ASN.1 standpoint =E2=80=93 so the minimum would be on= e byte.=C2=A0
= =C2=A0
A = single byte with all bits zero and two bytes with all bits zero are differe= nt ukm values because of the way that they are used in the ECC-CMS-SharedIn= fo structure.=C2=A0 Note that this would not be the case if the ukm value w= as only used as a salt value to HKDF.=C2=A0 I do not see any reason to spec= ify a minimum length of this value.=C2=A0 The only thing that is required i= s uniqueness, EKR is correct about saying this.=C2=A0

I suggest:

=C2=A0 =C2=A0The ECC-CMS-SharedInfo entityUInfo field optionally contains=
=C2=A0 =C2=A0additional keying material supplied by the sending = agent.=C2=A0 Note that
=C2=A0 =C2=A0[CMS] requires implementation= s to accept a KeyAgreeRecipientInfo
=C2=A0 =C2=A0SEQUENCE that in= cludes the ukm field.=C2=A0 If the ukm field is present,
= =C2=A0 =C2=A0the ukm is placed in the entityUInfo field.=C2=A0 When present= , the ukm
=C2=A0 =C2=A0ensures that a different key-encryption ke= y is generated, even when
=C2=A0 =C2=A0the originator ephemeral p= rivate key is improperly used more than
=C2=A0 =C2=A0once.=C2=A0 = Therefore, if the ukm field is present, it MUST be selected in
= =C2=A0 =C2=A0a manner that ensures a unique KDF output;

Is this actually possible? The KDF is basica= lly a PRF, so there is some
chance that 0*128 and 1*128 produce t= he same output.

<= /div>
s/ensure/will with very high probability produce/

Russ




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


--94eb2c08763aff2559054f438ca7-- From nobody Thu May 11 12:04: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 71ECC131488; Thu, 11 May 2017 12:03:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149452943142.16669.548403308001100105@ietfa.amsl.com> Date: Thu, 11 May 2017 12:03:51 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-05.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, 11 May 2017 19:03:51 -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-05.txt Pages : 6 Date : 2017-05-11 Abstract: This document describes the conventions for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 11 12:22: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 D7D6D12942F for ; Thu, 11 May 2017 12:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEsZ_oRJfMHn for ; Thu, 11 May 2017 12:22:44 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0106.outbound.protection.outlook.com [104.47.32.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC91212E856 for ; Thu, 11 May 2017 12:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fB+yMD4wcIl5ShI7oZMAIlzFMgbtmy/OFvqomWRc80s=; b=Zr2QMNB9bgxZ9U4nzhAeegNDxP6vo3Cghhv5XE0ZEbFpJWYvGRgDSgHORZh+Mebe26oaSNyIy4UpGLQamEE4YryYYGSQOBKq/Q7kKtXZzijN87a/PtILazsfGwJXDmGVpzG+u2hFCzxKAp7YntkuAl8hG5AhUls89gFyetJdFJw= Received: from CO2PR05CA028.namprd05.prod.outlook.com (10.141.241.156) by MWHPR05MB2909.namprd05.prod.outlook.com (10.168.245.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 19:17:32 +0000 Received: from BY2NAM05FT052.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::203) by CO2PR05CA028.outlook.office365.com (2a01:111:e400:1429::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5 via Frontend Transport; Thu, 11 May 2017 19:17:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT052.mail.protection.outlook.com (10.152.100.189) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 19:17: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; Thu, 11 May 2017 12:17:31 -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 v4BJHUPa029922; Thu, 11 May 2017 12:17:30 -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 66B5B1144E; Thu, 11 May 2017 12:17:30 -0700 (PDT) To: Eric Rescorla CC: curdle In-Reply-To: References: Comments: In-reply-to: Eric Rescorla message dated "Fri, 05 May 2017 12:33:00 -0700." From: "Mark D. Baushke" Date: Thu, 11 May 2017 12:17:30 -0700 Message-ID: <34186.1494530250@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(39860400002)(2980300002)(9170700003)(5660300001)(6916009)(2950100002)(7126002)(53936002)(8936002)(189998001)(5003940100001)(229853002)(47776003)(86362001)(77096006)(6392003)(8676002)(7846003)(81166006)(7696004)(4326008)(2810700001)(2906002)(305945005)(356003)(54356999)(76176999)(50986999)(48376002)(50466002)(6306002)(110136004)(38730400002)(117636001)(55016002)(53416004)(105596002)(6246003)(6266002)(478600001)(230783001)(106466001)(76506005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2909; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT052; 1:kVES1TH46zjE89LcRN2lsqTFeRTL669cguxY6cgrgFTCKW8hkJISAfAPE0AMoMq7qA7IIuJ4h/gtCpsAeboNGNqKVENjoPsdHTCZRn7t3UxrzsxzDNNu/exr5zCpaEmKHU5cwqzlPHZQjw7HavNjf1Cv9+wOVbQO+6y4Y/m06Jy9xy6IujAMQ2Olq9HYlXRkmwxjdgrorVBN2HIaCp9Uta16znp2bcFDpG14aprLjkJwPwYKu+jEc4x7eJLaAeSPy74KcCN76sUugTtFr3L/Z32IrAbSFNzX7AmpzId0/ik9QMufFyRYMk6EHkFUPn2/OBCe7b558LX//pRgmeXZTBvn2C9x6zHQQQ69ivuEVZUoZJlGdvrDegSz8FhACpEwk8yqu8q1igdw8hUbK5b8fj1Z69X7H/94R6qdz7rj+XAPtWx7GqEGjOiQl4TuPz0heYNTlsEjcbzU8PoDXxVxX8YeXiHjTZ2gWOLTiu/TL6KVpYDBfvgcCYT0nj/DoNrV7WDdHccWpyBi72eprPPBwdhE3DRqYktRjCiW3kNIPJ9aGqVAT2HhTTMJbAVQVkvJM69/mc9yW2gh/RN3WqM7ejUlJzVwao8N1dYdTxnHbGo= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6913b7ca-598a-473c-4204-08d498a25f82 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR05MB2909; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 3:fqBBfJ0Qf82morzkwQ2EJAR48ew2B2vUVXW5J6licDR+cyMR41R2JJOBFWw6RHmnAED5tqFwUZu2gK3UoSmM5QIai+7pHUoTxdb6TGHYf3q40PfL3k4R87gHk7Hf/ABOwLwSr23ddtxPNKntuehdkuUkn0Yf5M4a3W7H5T3R/AsIG7Ako1+3mQ9RT0+T1T+HGgynZ62yuh3Klb9Is/VM4rKXjIoJynPkA2LhZyV6Es+H1nD87OXPqZE+ApdEDyQgAczvqcEwllMjvhn98cJEUjo2ZQTVGjPEiHRSY6NV61d5dw4q6GxJbnr8hWV3QzpuiTu3RzR5EUdy+8rYipCAStf4vyLt2HTa+2jVd2TyKDEN4eCZeNBvIEvOP5jeWGUgtXLA7Dej3+9p0JiGngWfyqweELOKfARRzL4DTOSXVhUc3recNrhaSyP5N0E9JFEBV60l5wgKn9L6xtQyZMWTT0itlDL7d0bAvufldfL+Lw5i142Rjx9XxKWfwK3VvKIn X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 25:OwYg2AQEIdULpjrDgC7bq16f5MR082AvMEcT/2GCaVnPPuAqrEMP404ZidFOEAw9DHmZ3y+pTsKe2CAJQY6bpkGWyLcORMuaq6sTw+N1IKJsFPvxq5GkxfnnA9XkSPTZr7butXdKuKSccNGWuQrWfCL+05zqfM844UEubTuBjVysDi7FziyW4uuy8jb9yLDxPGPB9Ab88aU1KWeRj72sI/2So7k8itxCkFNmdA4ATBEKZCZnbsGF2tiPmESyVeY15CpbAkmwqBxyiw7nxz5DYj1mhBvRCguXhXDJtVKJsjcDKURYseX9stz0DfC9nXYI8Klk3WQ1UhPhjXKHYY9+lN/0OtfHV+rfSMHu4kFmNVxIqRVRc34JApc+r7fAA6uMlGzshLzpHVr3xr+wz79Kv2ZPvozywCY64GtmJcHtPPDa0vF2Oznkl8ebTvl/uLxAQgloTON7/55iG5V7Y+bM3nMPSoZ5tJv8dKxrgUebqOg=; 31:eB1Nrs6SFXoWGQUTq+8ugGXHvcDyWnoty2oO2ksVvwcRVPr3mHtHtVJvjJf0hdBPykpCjMnVnw5be56ezkzkFl3z+2oW/Q385yHkdlc7uM4B5LBC8xohjOkdjNNBpBrxsYErLmTiWgZfRcCzngGQiORTzZBPio/b8PvPRsF3+DkN+1O/COZmSaHi72fmVatCQbp6AaaxJE89ZANy1j4Dl2LstahKSfmJQoKeslSWn1pRfORfqy249b7DAPJPs+9hItGAeoNcztVf9pQLbEFSzw== X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 20:GCV9MfVllo1vyVeIwgbkI6EXtAXya+Gw3Tj3UDAMhLiAuuDydfMIMxskIShSHSj+jZOkdMXRsuOgCi8JJk/eKFrtvqLe7djqzjnE1Wlt6tGNv+dWMzIuCBU2iw09NymVr8FQTT5R4PIg64dg/NbOfV1lxx68M1RFrMvI88tX215WN3Qs8PftnpdHP/BEu18SuySaZ5B4BS10zqEpPsmEVidT4tpFZpycXWbWAOzlt7h7CGo6gRj+k2xFziFk5T4tWGag96KmejjvOqqI3940iyl85FlGTT86yXsLa1zsQdDMKME8BmGI43Z4mkIjtZ1hisLjxWm0xgAmhNOCVhonSNDWkLyva9Ad3bW5QCh7PVtboWlN4oyv9FbeOr9ZSeXFg9AIshmf+SO+OXidN8B1QiHQy7NR6LelDIoDg64B9B0kHFE+i9e/I+4Fz0dKzPyALl4bo5bB2dcjj8gG8glsOZeXMM8g4qARYaJXAN+2HOJazNeYWWMV33XOqV1E65zM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(13017025)(8121501046)(13018025)(13024025)(13015025)(13023025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148); SRVR:MWHPR05MB2909; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2909; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 4:Zpv30ZIfKoxRR9TP8Ellfyl9bE/N7iTxVlU1YCnG6BHwC5askhCoIxOu3X7ySIBN4rpky4YaZ5WjxLHZldeLtLJ0Q9bfj5TseZtXRbtw01kaFpMb907zPgaAsvWGqf7SK42GKToJMnHkxZ5X6glFNJuP7pW/j5q2bhFSvdqfJ+IK/oS9HqaxW1oRJevJmR2cJIly8fLqHzSHj5anY1uVOhXYOtcipqJSk1r1l81qNCVGJ9E5/Gf4cyeicP5HM3nVUzGRY+Z4CS83PPHs6ZVXeZtBeEqhQDGNiHUoSumqTr/VpxVoo8biFskUKyT0f41SRi9CNAnMLpGZmoOiegWh3YeP5F5IWZDKIw6NEycngPtGUcHJFd4Lux10x/07JBlaOld9HoWyfY8QLphtDPn1a7EGyMs04EKWpZqfOgTrOLXeRCmrskZ8UdFqGIgX6XTaveiT5MaYR8AqDl0khp2fo6dPOamqIa3/ws3ZFiig1kO9a606MjTCiwpzILeZ8CDMFNA3i5NG0zDa/YnW7rYhe03XdHNkA1JqHk4miFgSQQlcp1t1TtZNh9+7GkKhfaFNH2Jth26y9WQ16c4JQmQRMAZZNhA2IC9nI4slrPO7dDenGFVZnQP2yy9LN+LBkT6eguckLJklp0A5TxSchuNETPYj1FZ7GCQsEz8B4o7D+ABG9fwgySIVOeheNio6jbY0r9OeG0ERlV2rEUskKKOuS4G1gbd1h8U0oSiNb4l17zfvV4KCoqr2z/i0Lg8zGpMUIOZkGaeSfXEMaKHcu6xL5WmezNWBQbupxxD6cVqs87rOjX7PV3tBxb2sd1FW5xymh3CZo0+dMLWABC/GG+UYKO7dQzY5PvT5etNPICv0Dq2GKIZSIRYeIXRfzeDcfh06GfWHZjZiIc3sz0u5H/DUww== X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2909; 23:R3n9Pgz+SsKe4Rwzoi3v7ygXkOI4iyEEfml/xVuF1?= =?us-ascii?Q?yM8rZ28rwkIaBBp+Lte+ZJiIRGmhsZ0rM44jNg6U4vT8SR0pe559g1qOMMxm?= =?us-ascii?Q?BSRhSTirjSKVmwX6IFqMNUY+RZKP9Ipi6raTCSsk3C6w7niCkSDbkAXU9Px6?= =?us-ascii?Q?LknfrtIbanCURFzV2RcoCcmMqfNrvGvYQG/pp9WruefGwv1mU312VX+LMuaT?= =?us-ascii?Q?m8k+epeBPlqEMzbnbf0MFRdgc2R7W5ayAfaemVHmClGfDCeDazr70jNOdBFN?= =?us-ascii?Q?VRjCJeK+1yp3bgJf60U9hXkGrPKoEiXpB6BWkjDqS9BUv+8b+wyRTYle/oXu?= =?us-ascii?Q?DaEOJWT3hHB1ZDdVFc3tzSZl5mrOGkp9hTDK2ut6404r2zXowZKPLhwDCKTC?= =?us-ascii?Q?KnhGDqos7QLgo4d8Hq437bjYbcae2nhiclQRLxganFIRXOjiMpR7Hv9CNw+H?= =?us-ascii?Q?KRGsrSonY0qj11IeSHDuIcz7IqvRwyeP7Gz5wZB4jSw8MIcbYYc1DBEZJU1w?= =?us-ascii?Q?FYGGbnOZU8kJCggROg1yC631+L2c8VWbcvPqYp0bos5mhbh0mBAXd7WjTbKb?= =?us-ascii?Q?9Dbipb2hrEdBdgXpuPJ2LUPqcOalIAwwAW+aBDjfr9xWBihmq6SnBANes/zW?= =?us-ascii?Q?GyzV3wMsOO1+NEF/lBZtetqO3Dl64fG5sG8UB1bcqGZHBDKE/a4jBoi64rDQ?= =?us-ascii?Q?LgWpxHGgleCPsREb/4bapH2LzHlbLTXNyz4F4QuNv5yMDplWmP/BgaWnuhci?= =?us-ascii?Q?Y3wRMLctBt6grpyc9rvEZmjdLRghrJPkhgmrT0iXtcddVyJSXQOJeVPHMRFf?= =?us-ascii?Q?puMKMtlsFj5q/X20aMBJgXa6E43D+vXfHUt8lTrwaIDt8U7LgxKo59VkxNP3?= =?us-ascii?Q?STMbHjg9IZp7SRlkYGqK+VmDXYosVxtuOtSxYpkur8I0RhUASal3UqQmVQJs?= =?us-ascii?Q?2w5HW00EtILzwg5hg8eWLAlJ7pEydn/tIgmJTNV7VqTjwF/8dJjABcrWqvKj?= =?us-ascii?Q?Tqa+2loSicnwrdKXEOlF2A6R5WLzaZMLATe5ISuyzLLD8FWXvboXA24AzNAJ?= =?us-ascii?Q?krPC/0xJwVJa5fAEw/p8+KGcXcE8spg0QShb6HWKqdXVttOogElbt78UbMbK?= =?us-ascii?Q?QcB3aSxX53Ydldqsw9eODfu8Da4SThDDVxvfei46A0vuI10r0gSuUgNG1zkI?= =?us-ascii?Q?0akoxl91OiX4LCCFhU4VGq3GXNsNfXF8y0YpXgADqA6gnG5IsRzAhqBHzz5X?= =?us-ascii?Q?asUWwHjtl9g+uvVFLw=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 6:smXuaXpqTVGC3EPTDHw5NCHbRtGANBe+GnY2qTjuP/QSKaOptPum71NIqQZ2oWEaCa/64dqv87zEsdc4HiuugbsZsqSK/M59pI7eM4bKTHkj05LMl0aj7LNr8aXsOBf2rklY+muBNtRs2hZpgOm2lzlCz0FQHv1Lc4XL3KSF0EU4h1MzcESd2YAlmuUE5qIOddFuPA+j/2GPjm8Z/zq0+hHd1wAAkleBRCtPOwOVAxRQ7OZfrDYfhOcYRyN/3siGDVTLwwLQJVADvP3Qe0V23yraSk5uG+D0xX+xT7EwSQknnnRCcdB1YaoOTvV6IaYy+WK53pNGFIdmXhsuLn4YNDGDtSHS5J4rjqF9F0iopHdq//TH2LWfvbDfnEvA+qKh6ULj0JvyiIOQnn5oFNj/n1ohAHzDHYYQazG5Sp0+e363B8+/eS8bAOtBH4EUbw4lYlXZsgEfTy9GZhnVbgSCu/eliVcCcAB8UJYdG+O89YMEUWbMh+qB/SQKOiafsA/cZTsXoOLYjviuuFUffhe5kMoEpoNOJSyR9rLFKw+/XHg=; 5:cyUxsJUew+bsfwqQesHcpdKoGAZwja3j6osqYC0rhePyL3NBndw76QQnfn8FMm5jBV7KcytoXiojStCH7HFQyxUCnujaKDqvqQqn89UbsepDTGpiNQWR0rSI35C+Bbch9Nij3bbA9rMr6TN5pm2ODA==; 24:FuSJRZrnEQEqHOk5fd6lmcn7t3xJrPzl+HOQSqaFABY+YFmSgFj35cJf35xL4nSOA/ifpbQq3QYvlPGLcx/O6AfidIAibJii3hcvNz+BpYA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2909; 7:djS5wxfnJm7RjgGM7wCMdpNNa/jdOC9pekADwor3C1J2t8mZoeWKjZGJSPl/WBSglCL7I4R4tsYJk2uTKikYYzMraVF+vyRpcuA0wfL6jXI4/AcU0LvhEEuGfoiCCPXJEvX0bE9D+DDwGfKc2ddp8qk9ExOSyszn8qXCm5Gk/SoRGEts7A557CK/HyuSMxQgkOIMuns7N9qeQgqV93t9zKf4jp/YEjXSboGlO4DzJalUNASI6zbdHiWeO/H5+2EmXt9HxkysdGsNuIcBfup07MmQocbfnoct9JzPb7ZhoSXyBaDyjEakTI8oBusDe6fQDRGLd2VGkDMxaCmSaMhvQQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 19:17:31.8286 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2909 Archived-At: Subject: Re: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-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: Thu, 11 May 2017 19:22:46 -0000 Hi Eric, The updated draft-ietf-curdle-ssh-curves-05.txt should address all of your concerns. I also ran throug the idnits tool (URL: https://tools.ietf.org/tools/idnits/) and moved informatonal RFCs: RFC6234 and RFC7748 from "Normative References" to "Informative References" to remove the last two errors. I hope this edition is sufficient to pass the AD Review. Please let me know of any remaining issues with the document. Thank you, -- Mark From nobody Thu May 11 12:43:20 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A0E12946F; Thu, 11 May 2017 12:43:18 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149453179830.16644.10052346077067352686@ietfa.amsl.com> Date: Thu, 11 May 2017 12:43:18 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-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: Thu, 11 May 2017 19:43:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-07.txt Pages : 16 Date : 2017-05-11 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-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 Thu May 11 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 10DFE1314E7 for ; Thu, 11 May 2017 12:49:52 -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 OU3awT-MU9QY for ; Thu, 11 May 2017 12:49:49 -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 96119129C6D for ; Thu, 11 May 2017 12:44:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DBE46300526 for ; Thu, 11 May 2017 15:44:23 -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 qJ68SFE-OLdZ for ; Thu, 11 May 2017 15:44:19 -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 29552300265; Thu, 11 May 2017 15:44:19 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F85DAD3C-27C6-4DAF-A495-56C29D71CADE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 15:44:19 -0400 In-Reply-To: Cc: Jim Schaad , curdle To: Eric Rescorla References: <5EEB2415-61EF-4B6E-91CA-EE2EB7C3E087@vigilsec.com> <013101d2c8ec$586cd450$09467cf0$@augustcellars.com> <30A1145E-F049-454C-93AB-1445767BA67C@vigilsec.com> <016801d2c901$5e299760$1a7cc620$@augustcellars.com> <1D0D6254-2E6E-4EDD-9FF6-385DA561013D@vigilsec.com> <111B20E8-5253-4A5A-A39E-6926D9350136@vigilsec.com> <14BFAE56-7FA4-454D-9447-F7DB6492CB28@vigilsec.com> <597A9F82-7861-4680-ABFE-ADA1E26C79EE@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-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: Thu, 11 May 2017 19:49:52 -0000 --Apple-Mail=_F85DAD3C-27C6-4DAF-A495-56C29D71CADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, that is more clear. I just posted = draft-ietf-curdle-cms-ecdh-new-curves-07 with that update. Russ > On May 11, 2017, at 2:13 PM, Eric Rescorla wrote: >=20 > Nit, I think you should specify alternative to what. >=20 > If an > alternative implementation of these elliptic curves to that = documented > in [RFC7748 Section 6] is employed, then > the additional checks specified in Section 7 of [CURVES] SHOULD be > performed. >=20 > On Thu, May 11, 2017 at 9:15 AM, Russ Housley > wrote: > To make it flow with the text that is already there, I suggest: >=20 > X25519 is described in Section 6.1 of [CURVES], and X448 is = described > in Section 6.2 of [CURVES]. Conforming implementations MUST check > whether the computed Diffie-Hellman shared secret is the all-zero > value, and abort if so, as described in Section 6 of [CURVES]. If = an > alternative implementation of these elliptic curves is employed, = then > the additional checks specified in Section 7 of [CURVES] SHOULD be > performed. >=20 > Russ >=20 >=20 >> On May 10, 2017, at 6:06 PM, Eric Rescorla > wrote: >>=20 >> I apologize but I just took a look at the language around invalid = points. I would suggest >> you use the same language as TLS here: >>=20 >> For X25519 and X448, implementations SHOULD use the approach >> specified in [RFC7748] to calculate the Diffie-Hellman shared = secret. >> Implementations MUST check whether the computed Diffie-Hellman = shared >> secret is the all-zero value and abort if so, as described in >> Section 6 of [RFC7748]. If implementers use an alternative >> implementation of these elliptic curves, they SHOULD perform the >> additional checks specified in Section 7 of [RFC7748]. >>=20 >> LMK what you think. >>=20 >> Best, >> -Ekr >>=20 >>=20 >> On Wed, May 10, 2017 at 6:50 AM, Russ Housley > wrote: >> Yes, that works for me. I=E2=80=99ll post an updated I-D later = today. >>=20 >> Russ >>=20 >>=20 >>> On May 9, 2017, at 7:59 PM, Eric Rescorla > wrote: >>>=20 >>> I guess I would focus on the uniqueness of the input, because the = output's uniqueness is largely a function of: >>>=20 >>> 1. Input uniqueness >>> 2. The number of discrete inputs. >>>=20 >>> So, I think I would say: >>>=20 >>> "it MUST be selected in a manner that ensures it is unique with high = probability" >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>> On Tue, May 9, 2017 at 3:35 PM, Russ Housley > wrote: >>>=20 >>>> On May 9, 2017, at 5:16 PM, Eric Rescorla > wrote: >>>>=20 >>>>=20 >>>> On Tue, May 9, 2017 at 1:25 PM, Russ Housley > wrote: >>>>>>>> > The ECC-CMS-SharedInfo entityUInfo field optionally = contains >>>>>>>> > additional keying material supplied by the sending agent. = Note that >>>>>>>> > [CMS] requires implementations to accept a = KeyAgreeRecipientInfo >>>>>>>> > SEQUENCE that includes the ukm field. If the ukm field is = present, >>>>>>>> > the ukm is placed in the entityUInfo field. The ukm value = need not >>>>>>>> > be longer than the key-encryption key that will be = produced by the >>>>>>>> > KDF. >>>>>>>> > >>>>>>>> > Need not? Please clarify what the purpose is here. It seems = like >>>>>>>> > it's to generate a unique KEK. In that case, the security = bounds >>>>>>>> > are what, uniqueness? >>>>>>>>=20 >>>>>>>> I suggest this wording: >>>>>>>>=20 >>>>>>>> =E2=80=A6 There is no security benefit to using a ukm value = that is >>>>>>>> longer than the key-encryption key that will be produced by >>>>>>>> the KDF. >>>>>>> =20 >>>>>>> Hmm... I believe that this statement is true, but it also seems = to be >>>>>>> incomplete. I may be reasoning about this incorrectly, but it = seems >>>>>>> to me that the minimal security requirement is that the UKM be >>>>>>> unique, but that can be achieved with a value much smaller than >>>>>>> the KEK. For instance, it seems like if you have a 256-bit KEK, >>>>>>> then you would still be OK with a randomly-generated 128-bit >>>>>>> UKM. And if we're concerned about random collisions, then the >>>>>>> usefulness bound is actually min(|KEK|, |hash compression = function size|). >>>>>> =20 >>>>>> Yes. The umm value needs to be different for each invocation of = the KDF, otherwise it does not provide the assurance that different = keying material will be produced. Of course, an implementation will = generate the umm value using random number generator, not track the = values that are used. Several years ago, there was a discussion about = the size of the ukm needed. Some people were suggesting crazy large = values, and the point was made that anything beyond the SIZEOF(KEK) did = not improve security. >>>>>> =20 >>>>>> Are you asking for a sentence saying that the ukm, if present, = MUST be at least 128 bits? >>>>>> =20 >>>>>> [JLS] I would disagree that the value has to be random, a counter = will work as well. (An encrypted counter is better.) I not be happy = with a fixed size requirement on this easier. There is no reason to = make such a requirement that I can think of. A 64-bit counter is just = as rational. It might make more sense to change this statement into = something along the lines of=20 >>>>>> =20 >>>>>> * Any pair of static keys MUST NOT be used more times than the = size of the key. I.e. if 128-bit KEKs may be used, then there is a = 2^128 limit on the number of times the key pair can be used. >>>>>> * The size of the KEK is normally not longer than the length of = the resulting KEK as that is the limit of unique values that can be = generated in any event. >>>>> =20 >>>>> Section 2 already says that the ephemeral key MUST be used for = only one message. Thus, a UKM is not really needed. However, the CMS = requires support for a UKM if the sender include it. For this reason, = the document says how to handle it in the KDF if it is present. >>>>> =20 >>>>> You are correct that a counter, encrypted counter, or random value = will work, even if the originator uses the same ephemeral key for many = messages. The text does not limit the choices in any way. >>>>> =20 >>>>> The text already says that there is no security reason for a UKM = value that is longer than the KEK. I think that EKR is asking for = guidance on the minimum size too. >>>>> =20 >>>>> [JLS] It=E2=80=99s kind of a stupid thing to do, but the minimum = size would be one bit. Although this is not legal from an ASN.1 = standpoint =E2=80=93 so the minimum would be one byte.=20 >>>>> =20 >>>>> A single byte with all bits zero and two bytes with all bits zero = are different ukm values because of the way that they are used in the = ECC-CMS-SharedInfo structure. Note that this would not be the case if = the ukm value was only used as a salt value to HKDF. I do not see any = reason to specify a minimum length of this value. The only thing that = is required is uniqueness, EKR is correct about saying this.=20 >>>>=20 >>>> I suggest: >>>>=20 >>>> The ECC-CMS-SharedInfo entityUInfo field optionally contains >>>> additional keying material supplied by the sending agent. Note = that >>>> [CMS] requires implementations to accept a KeyAgreeRecipientInfo >>>> SEQUENCE that includes the ukm field. If the ukm field is = present, >>>> the ukm is placed in the entityUInfo field. When present, the = ukm >>>> ensures that a different key-encryption key is generated, even = when >>>> the originator ephemeral private key is improperly used more = than >>>> once. Therefore, if the ukm field is present, it MUST be = selected in >>>> a manner that ensures a unique KDF output; >>>>=20 >>>> Is this actually possible? The KDF is basically a PRF, so there is = some >>>> chance that 0*128 and 1*128 produce the same output. >>>=20 >>> s/ensure/will with very high probability produce/ >>>=20 >>> Russ >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle = >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_F85DAD3C-27C6-4DAF-A495-56C29D71CADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, that is more clear.  I just = posted draft-ietf-curdle-cms-ecdh-new-curves-07 with that = update.

Russ


On = May 11, 2017, at 2:13 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

Nit, I think you should specify alternative to = what.

  If an
   alternative = implementation of these elliptic curves to that documented
   in [RFC7748 Section = 6] is employed, then
   the additional checks specified in Section 7 of = [CURVES] SHOULD be
  =  performed.

On Thu, May 11, 2017 at 9:15 AM, = Russ Housley <housley@vigilsec.com> wrote:
To make it flow with the text = that is already there, I suggest:

   X25519 is = described in Section 6.1 of [CURVES], and X448 is = described
   in Section 6.2 of = [CURVES].  Conforming implementations MUST check
   whether the computed = Diffie-Hellman shared secret is the all-zero
   value, and abort if so, as described in Section = 6 of [CURVES].  If an
   alternative = implementation of these elliptic curves is employed, then
   the additional checks specified in Section 7 of = [CURVES] SHOULD be
  =  performed.

Russ


On May 10, = 2017, at 6:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:

I= apologize but I just took a look at the language around invalid points. = I would suggest
you use the same language as TLS = here:

   For X25519 and X448, implementations SHOULD use = the approach
   specified in [RFC7748] to = calculate the Diffie-Hellman shared secret.
  =  Implementations MUST check whether the computed Diffie-Hellman = shared
   secret is the all-zero value = and abort if so, as described in
  =  Section 6 of [RFC7748].  If implementers use an = alternative
   implementation of these = elliptic curves, they SHOULD perform the
  =  additional checks specified in Section 7 of = [RFC7748].

LMK what you think.

Best,
-Ekr


On Wed, May 10, 2017 at 6:50 AM, = Russ Housley <housley@vigilsec.com> wrote:
Yes, that works for me.  = I=E2=80=99ll post an updated I-D later today.

Russ


On May = 9, 2017, at 7:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

I guess I would focus on = the uniqueness of the input, because the output's uniqueness is largely = a function of:

1. = Input uniqueness
2. The number of discrete = inputs.

So, I = think I would say:

"it MUST be = selected in a = manner that ensures it is unique with high probability"

-Ekr



On Tue, May 9, 2017 at 3:35 PM, = Russ Housley <housley@vigilsec.com> wrote:

On May = 9, 2017, at 5:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, = May 9, 2017 at 1:25 PM, Russ Housley <housley@vigilsec.com> wrote:
>    The ECC-CMS-SharedInfo entityUInfo field = optionally contains
>    additional keying = material supplied by the sending agent.  Note that
>    [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
>    SEQUENCE that = includes the ukm field.  If the ukm field is present,
>    the ukm is placed in the entityUInfo = field.  The ukm value need not
>    be = longer than the key-encryption key that will be produced by the
>    KDF.
>
> = Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the = security bounds
> are what, uniqueness?
I suggest this wording:

  =  =E2=80=A6 There is no security benefit to using a ukm value that = is
   longer than the key-encryption key that = will be produced by
   the KDF.
 
Hmm... = I believe that this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it = seems
to me = that the minimal security requirement is that the UKM be
unique,= but that can be achieved with a value much smaller than
the = KEK. For instance, it seems like if you have a 256-bit KEK,
then = you would still be OK with a randomly-generated 128-bit
UKM. = And if we're concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression = function size|).
 
Yes. The umm value needs to be different for each invocation = of the KDF, otherwise it does not provide the assurance that different = keying material will be produced.  Of course, an implementation = will generate the umm value using random number generator, not track the = values that are used.  Several years ago, there was a discussion = about the size of the ukm needed.  Some people were suggesting = crazy large values, and the point was made that anything beyond the = SIZEOF(KEK) did not improve security.
 
Are = you asking for a sentence saying that the ukm, if present, MUST be at = least 128 bits?
 
[JLS] I would disagree that = the value has to be random, a counter will work as well.  (An = encrypted counter is better.)  I not be happy with a fixed size = requirement on this easier.  There is no reason to make such a = requirement that I can think of.  A 64-bit counter is just as = rational.  It might make more sense to change this statement into = something along the lines of 
 
* Any pair of static keys MUST = NOT be used more times than the size of the key.  I.e. if 128-bit = KEKs may be used, then there is a 2^128 limit on the number of times the = key pair can be used.
* The size of the KEK is = normally not longer than the length of the resulting KEK as that is the = limit of unique values that can be generated in any event.
 
Section= 2 already says that the ephemeral key MUST be used for only one = message.  Thus, a UKM is not really needed.  However, the CMS = requires support for a UKM if the sender include it.  For this = reason, the document says how to handle it in the KDF if it is = present.
 
You = are correct that a counter, encrypted counter, or random value will = work, even if the originator uses the same ephemeral key for many = messages.  The text does not limit the choices in any way.
 
The = text already says that there is no security reason for a UKM value that = is longer than the KEK.  I think that EKR is asking for guidance on = the minimum size too.
 
[JLS] It=E2=80=99= s kind of a stupid thing to do, but the minimum size would be one = bit.  Although this is not legal from an ASN.1 standpoint =E2=80=93 = so the minimum would be one byte. 
 
A single byte with all bits = zero and two bytes with all bits zero are different ukm values because = of the way that they are used in the ECC-CMS-SharedInfo structure.  = Note that this would not be the case if the ukm value was only used as a = salt value to HKDF.  I do not see any reason to specify a minimum = length of this value.  The only thing that is required is = uniqueness, EKR is correct about saying this. 

I suggest:

  =  The ECC-CMS-SharedInfo entityUInfo field optionally = contains
   additional keying material = supplied by the sending agent.  Note that
 =  [CMS] requires implementations to accept a = KeyAgreeRecipientInfo
   SEQUENCE that = includes the ukm field.  If the ukm field is = present,
   the ukm is placed in = the entityUInfo field.  When present, the ukm
   ensures that a different key-encryption key is = generated, even when
   the originator = ephemeral private key is improperly used more than
   once.  Therefore, if the ukm field is = present, it MUST be selected in
   a = manner that ensures a unique KDF = output;

Is this actually possible? The KDF is = basically a PRF, so there is some
chance that 0*128 = and 1*128 produce the same = output.

s/ensure/will with very = high probability produce/

Russ





_______________________________________________
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=_F85DAD3C-27C6-4DAF-A495-56C29D71CADE-- From nobody Thu May 11 13:06: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 2106C129B31 for ; Thu, 11 May 2017 13:06:21 -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 4UsmUQCefjWa for ; Thu, 11 May 2017 13:06:19 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A542C129B5D for ; Thu, 11 May 2017 13:00:26 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k91so28509808ioi.1 for ; Thu, 11 May 2017 13:00:26 -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=Yi3Q7naupi9qkTcTX8D3dd3wo4t8kYh8qfJX7YgDPmc=; b=OnxmU8K5AFK7/X/9UlB2nAJqesbwJRf74gfW0Q4qqs0NpM+IrXIl9w05ug8nTtev3v Gbx1p5PWa/2rmKpZmstSfRCO068+Tyc9jcu8F3BGle/Zzmsvj0B1Ej+0JmMWFzroLf4+ ZlYN7ygnDYYuOVwvHPyAM8n5xCIBKycSa+scPrIWIGdBqZndQZLEeVl2J38r12NECJu+ nMvACN/slyZAEYAva3JGi+G98UvSxckEm/pdjkVV/Ulfqa9htCtzKfRKYKYcdlpXPrlp qbVGmi2jWkl0JWxVBXKjtgLqhPrNJw/Et/tIKw6Hdt7YbANW55QXWt9kDLF5+id9cpOC Y8RQ== 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=Yi3Q7naupi9qkTcTX8D3dd3wo4t8kYh8qfJX7YgDPmc=; b=qKu1cW8KRs1HmKFGzcrYSWSXjqBm0YvhO9EMT9KqcpzMgN/6Bhn7KnPmPS0LH/nApL lfLCHInXsoJZ2imdWYlLRDxnWDs9sF4PORCITDRZuupUuO7M25OP4KKj3Lhgznn9weZZ kg5dfquJFwQzqLRXWBpZ6qFtZCfkQD79ShiqRf14hccKXsRJaSyhCQDpmRx3sRWymEha y4oqvjSfHUfA8BWjf+yc3A1b0ouTnay5WR7pBRBCUaBs/8u5hUP1XqznStRMec0Wr9ou 8WoBAvcCKLrDwLfUa5jAj/iqd4W00XyNCgtiaIyTaVvmNsUZxI2/Dgq0KSXmFg7ET8v6 hY+w== X-Gm-Message-State: AODbwcBVI9+Ba4rifXGmXcLQUghxdtKsWlIYSe4jFNV67rmT0XcTAF4N kiMEoztl7pmbkgUAr0/1RsKX7Qjmww== X-Received: by 10.107.52.79 with SMTP id b76mr287697ioa.150.1494532826008; Thu, 11 May 2017 13:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Thu, 11 May 2017 13:00:25 -0700 (PDT) In-Reply-To: <1494497413004.14332@cs.auckland.ac.nz> References: <1494497413004.14332@cs.auckland.ac.nz> From: Brian Smith Date: Thu, 11 May 2017 10:00:25 -1000 Message-ID: To: Peter Gutmann Cc: curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Wanted: A valid PKCS#8 file with attributes 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, 11 May 2017 20:06:21 -0000 Peter Gutmann wrote: > Would PKCS #12 (containing a #8) do? I have some samples of > that created under Windows, however there's also the code > comment: Are the attributes in the PKCS#12 part or the PKCS#8 part? It seems like it would be good to find an attribute that makes sense for X25519 and one that makes sense for Ed25519. The point of the test cases would be to indicate that one shouldn't reject a PKCS#8 document just because it contains (an) attribute(s) that one doesn't process. Cheers, Brian -- https://briansmith.org/ From nobody Thu May 11 19:33: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 6987212EB05 for ; Thu, 11 May 2017 19:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 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_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1lkPPAqIpLM for ; Thu, 11 May 2017 19:33:20 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 9A7B212EB07 for ; Thu, 11 May 2017 19:27:33 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id m17so22626196pfg.3 for ; Thu, 11 May 2017 19:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ptbK9m7gtynEgdKDlQy+PclvKEzbeRRAQ42uJINpoTU=; b=LBhnnzFTaOw9dVA8R9z0TxkEwhk4gEZAO5/HE7wPY5yYfQz0R0XafBg2JZpoYHiBjG 7MjWFFUfXLfdoQDry4qprgvAwZyYb0A9220SWlNpGQWudgehnhnbKoI2Z9JjQyJpPQH3 uxKKgx4Rr3MyQojvbm1EhO/JsdJUHnVbznKXU= 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=ptbK9m7gtynEgdKDlQy+PclvKEzbeRRAQ42uJINpoTU=; b=QIFA0PhwznJT+2k749zorzoLJ2Y7pzupgiKTLU0sGqPqSdwu9ky0LD8b43pPM/9asN XldvQroQZbPmRPgXAP/8HYpUhkeXAzYiiihqS2a2uxSmkfAE4tUB6cSz4r3cUq0PqQvV meezhn0fcPJ8089usTYWwfCCjJ0vvEMJBKxGK7qpYkCM58/CX6f7FRaJEFYqrSYjZ+Zb wISl4L535z56j7aqvm8jnhSHJWVrYZCORQpJJxY8/fB4hwJIpQtuxTuUgEa0yzvI/z5r xl0XtmozOAx/samgfT1U5MOo5SDn8pxjgAxV4UJxCbqtpuWCiuOeJSYYITx2lhwNHAhm ELFw== X-Gm-Message-State: AODbwcCGPubpFg0EiEEBIHlcBJAB6DXTSqZRbYh/t1nPH/1oX9Tk+jqc Nvk/HY1N7NswJw== X-Received: by 10.99.178.11 with SMTP id x11mr1863019pge.68.1494556053230; Thu, 11 May 2017 19:27:33 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id w23sm2155910pfl.133.2017.05.11.19.27.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 19:27:32 -0700 (PDT) From: Ron Frederick Message-Id: <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 19:27:30 -0700 In-Reply-To: <36528.1494509552@eng-mail01.juniper.net> Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: "Mark D. Baushke" References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 12 May 2017 02:33:23 -0000 --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, On May 11, 2017, at 6:32 AM, Mark D. Baushke wrote: > Hi Eric & Ron & Brian & Simon, >=20 > Given input from folks so far, I think it would be better if both > Curve25519 and Curve448 continued to use the "mpint" format for K when > generating a hash even though this is not what RFC7748 suggests. >=20 > Would it make sense to include the following text to the end of = section > 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? >=20 > When performing the X25519 or X448 operations, the integer values > there will be encoded into byte strings by doing a fix-length > unsigned litle-endian conversion, per [RFC7748]. It is only later > when these byte strings are then passed to the ECDH code in SSH = that > the bytes are re-interpreted as a fixed-length unsigned big-endian > integer value K, and then later that K value is encoded as a > variable-length signed "mpint" before being fed to the hash > algorithm used for key generation. >=20 > to help clarify the differences between RFC7748 and what is happening = in > SSH? >=20 > Much of this text is borrowed from what Ron Frederick has written to = me, > any remaining confusion is my fault. >=20 > I think that the above text should help clear up the confusion that = Eric > noted in this section of code. >=20 > If there are no problems with this text, I will release the -05 draft > with it. I just took a look at the updated draft. Here=E2=80=99s a copy of the = text in section 2.1 and some inline suggestions: 2.1 = .= Shared Secret Encoding The following step differs from [RFC5656 = ], which uses a different conversion. This is not intended to modify that text generally, but only to be applicable to the scope of the mechanism described in this document. The shared secret, K, is defined in [RFC4253 = ] as a multiple precision integer (mpint). Curve25519/448 outputs a binary string X, which is [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80=9D= . I=E2=80=99d suggest saying =E2=80=9CThe shared secret, K, is defined = in [RFC4253] as an integer." the 32 or 56 byte point obtained by scalar multiplication of the other side's public key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the bytes as an unsigned fixed-length integer encoded in network byte order. This conversion follows the normal "mpint" process as described in section = 5 of [RFC4251] . [Ron] There are actually two conversions here, from the byte string X to = the integer K, and then from K back to a byte string to be fed to the = hash used for key generation. This text makes it sound like the = conversion from X to K should follow the =E2=80=9Cmpint=E2=80=9D = conversion, but that=E2=80=99s not the case. The sentence about how to = convert X into the integer K looks good, but I would drop the last = sentence here and begin a new paragraph which discusses the second = conversion from the integer K back to a byte string for insertion into = the hash, such as: The integer K is then fed along with other data to the key exchange = method=E2=80=99s hash function to generate encryption keys. During this = process, [RFC4253] specifies that K should be encoded as an =E2=80=9Cmpint= =E2=80=9D as described in section 5 of [RFC4251]. This conversion may = result in a value which varies from the fixed-length byte string X as = follows: This new paragraph can replace the next paragraph below. To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: o Trim all leading zero-bytes of X. If X is all zero-bytes, then the key exchange MUST fail. [Ron] Are you sure this is necessary? I don=E2=80=99t see any mention of = this restriction in RFC 4253. If the integer value of K is 0, it can = still be encoded as a valid mpInt. o If the high bit of X is set, the mpint format requires a zero byte to be prepended. o The length of the encoded K may not be the same as the original length of X due to trimming or prepending zero-bytes as needed for "mpint" format. [Ron] Actually, after doing all of this, the mpint conversion also = requires the that resulting byte string be preceded by a 4-byte = big-endian length value. So, even if the X value has no bytes removed or = prepended, it will be 4 bytes longer than it was originally. There=E2=80=99= s no mention of this length here. Or, as pseudo code: k :=3D x; while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; assert(k.length() > 0); if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; Figure 1 When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748 = ]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. [Ron] With the changes I have proposed above, I=E2=80=99m not sure this = last paragraph is needed. Alternately, I=E2=80=99d think about working = some of this text into the two paragraphs above that discuss the = conversion from X to K and then from K to an mpint. Also, = =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length=E2=80=9D= . I think it is better to cover this point before diving into the = details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from = the original X byte string. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mark,

On= May 11, 2017, at 6:32 AM, Mark D. Baushke <mdb@juniper.net> = wrote:
Hi Eric & Ron & Brian & Simon,

Given input from folks so far, I think it would be better if = both
Curve25519 and Curve448 continued to use the "mpint" = format for K when
generating a hash even though this is = not what RFC7748 suggests.

Would it make = sense to include the following text to the end of section
2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= ?

   When performing the = X25519 or X448 operations, the integer values
=    there will be encoded into byte strings by doing a = fix-length
   unsigned litle-endian = conversion, per [RFC7748]. It is only later
=    when these byte strings are then passed to the ECDH = code in SSH that
   the bytes are = re-interpreted as a fixed-length unsigned big-endian
=    integer value K, and then later that K value is = encoded as a
   variable-length signed = "mpint" before being fed to the hash
=    algorithm used for key generation.

to help clarify the differences between RFC7748 and what is = happening in
SSH?

Much of = this text is borrowed from what Ron Frederick has written to me,
any remaining confusion is my fault.

I think that the above text should help clear up the = confusion that Eric
noted in this section of code.

If there are no problems with this text, I = will release the -05 draft
with it.

I just took a look at the updated draft. Here=E2=80=99s = a copy of the text in section 2.1 and some inline suggestions:

2.1.  Shared =
Secret Encoding


   The following step differs from [RFC5656], which uses a different
   conversion.  This is not intended to modify that text generally, but
   only to be applicable to the scope of the mechanism described in this
   document.

   The shared secret, K, is defined in [RFC4253] as a =
multiple precision
   integer (mpint).  Curve25519/448 outputs a binary string X, which is

[Ron] RFC =
4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80=9D=
. I=E2=80=99d suggest saying =E2=80=9CThe shared secret, K, is =
defined in [RFC4253] as an integer."

   the 32 or 56 byte point =
obtained by scalar multiplication of the
   other side's public key and the local private key scalar.  The 32 or
   56 bytes of X are converted into K by interpreting the bytes as an
   unsigned fixed-length integer encoded in network byte order.  This
   conversion follows the normal "mpint" process as described in section
   5 =
of [RFC4251].

[Ron] There =
are actually two conversions here, from the byte string X to the integer =
K, and then from K back to a byte string to be fed to the hash used =
for key generation. This text makes it sound like the conversion =
from X to K should follow the =E2=80=9Cmpint=E2=80=9D conversion, =
but that=E2=80=99s not the case. The sentence about how to convert X =
into the integer K looks good, but I would drop the last sentence here =
and begin a new paragraph which discusses the second conversion from =
the integer K back to a byte string for insertion into the hash, =
such as:

The integer K is then fed along with other data to the key =
exchange method=E2=80=99s hash function to generate encryption keys. =
During this process, [RFC4253] specifies that K should be encoded as =
an =E2=80=9Cmpint=E2=80=9D as described in section 5 of [RFC4251]. =
This conversion may result in a value which =
varies from the fixed-length byte string X as =
follows:

This new =
paragraph can replace the next paragraph =
below.

   To =
clarify a corner-case in this conversion, when X is encoded as =
an
   mpint K, in order to calculate the exchange =
hash, it may vary as
   follows:


   o  Trim all leading zero-bytes of X.  If X is =
all zero-bytes, then
      the key exchange MUST fail.

[Ron] Are you =
sure this is necessary? I don=E2=80=99t see any mention of this =
restriction in RFC 4253. If the integer value of K is 0, it can =
still be encoded as a valid mpInt.

   o  If the high bit of X is set, the mpint format requires a zero byte
      to be prepended.

   o  The length of the encoded K may not be the same as the original
      length of X due to trimming or prepending zero-bytes as needed for
      "mpint" format.

[Ron] =
Actually, after doing all of this, the mpint conversion also requires =
the that resulting byte string be preceded by a 4-byte big-endian =
length value. So, even if the X value has no bytes removed or prepended, =
it will be 4 bytes longer than it was originally. There=E2=80=99s no =
mention of this length here.

   Or, as pseudo =
code:
                 k :=3D x;
                 while (k.length() > 0 && k[0] =3D=3D 0) k =3D =
k[1:];
                 assert(k.length() > 0);
                 if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k;

                                 Figure 1

   When performing the X25519 or X448 operations, the integer values
   there will be encoded into byte strings by doing a fix-length
   unsigned litle-endian conversion, per [RFC7748].  It is only later
   when these byte strings are then passed to the ECDH code in SSH that
   the bytes are re-interpreted as a fixed-length unsigned big-endian
   integer value K, and then later that K value is encoded as a
   variable-length signed "mpint" before being fed to the hash algorithm
   used for key generation.

[Ron] With the changes I have proposed above, I=E2=80=99m not = sure this last paragraph is needed. Alternately, I=E2=80=99d think about = working some of this text into the two paragraphs above that discuss the = conversion from X to K and then from K to an mpint. Also, = =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length=E2=80=9D= . I think it is better to cover this point before diving into the = details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from = the original X byte string.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747-- From nobody Thu May 11 21:20: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 41DE312E872 for ; Thu, 11 May 2017 21:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 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_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc1aUh1l2imt for ; Thu, 11 May 2017 21:20:20 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F81129BCC for ; Thu, 11 May 2017 21:14:09 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id q125so4813435pgq.2 for ; Thu, 11 May 2017 21:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zLgtFjoSSnK7slbxOd6HuxZBupb5pczlyImi4x98zY0=; b=dRORzJW+dASXkgD8TeipWNAmWGwumj3LbeXbsUkZnqAX5Q/wf4GQyRJBhqUt/ipb6e 6VvSetbdtWg0n8thLFIDV3H/XJQyt7P1C6p7zR6+CJNlQIwMe+5LDaGcRqy4WMzigvd1 IveuiAUmUHdQxBDgq8UprOuPIL19PtEi6YZ78= 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=zLgtFjoSSnK7slbxOd6HuxZBupb5pczlyImi4x98zY0=; b=j5VO2Cb1eOhRFCGFOY6c/JPE6taeGj3DWd7DKLofRz0M2xn+d8QdX3c89HnygVsnfW NMAw41iKWmSW8A9KUdlH3HPYF/vFSvjrliwi5euy5QDAz+3ldWWen8rtcFFlsIxgr6X5 X+6mc9BFnqzsLsQ5X8K6GgxoK2+DqMH+wM61DmvZfN6f5oDcslw+d6z4SLo8fUblUeOU +eNEzGjPoEpP4CtrHd9tGD2qWortccOMrqhMMbn4rjck0H8HJ9cuo9YLpj/QV3otH8+a C3emzyERJh//vAIznFshw8BrMuMwq3icja3oypKhowT5NvwJ77KYEwI5AR0/x3caBUYb Nr9g== X-Gm-Message-State: AODbwcAXjXW00kcozy6bY1mK5s9rPtUBG/ib8rZCloqF8mqt8si7Gm5Q WTcutMmknJg7GaCjsDJmNQ== X-Received: by 10.84.212.15 with SMTP id d15mr2883808pli.51.1494562448988; Thu, 11 May 2017 21:14:08 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id m89sm2504429pfg.22.2017.05.11.21.14.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 21:14:07 -0700 (PDT) From: Ron Frederick Message-Id: <2CC13809-AE05-49A6-9AAA-B196A70FC006@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_49EA0333-48D5-4D77-98BB-0F41FDBBC8DB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 21:14:06 -0700 In-Reply-To: Cc: curdle To: Brian Smith References: <1494497413004.14332@cs.auckland.ac.nz> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Wanted: A valid PKCS#8 file with attributes 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, 12 May 2017 04:20:21 -0000 --Apple-Mail=_49EA0333-48D5-4D77-98BB-0F41FDBBC8DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian Smith wrote: > I've been creating some test vectors for Ed25519 and X25519 PKCS#8 > files, some of which I've already shared on this list. I would like to > create some test vectors that include attributes, but I've not seen > any. If somebody could share an example of a valid PKCS#8 file with > attributes, especially ones that make sense for PKCS#8, that would be > very helpful. I support Ed25519 keys in AsyncSSH right now, but only in OpenSSH key = format. I wasn=E2=80=99t aware that there was a PKCS#8 representation = defined for these keys. Do you have a reference you can point at for = that? I=E2=80=99d love to support it if a standard exists for it. In a search, I just ran across = https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 = =E2=80=94 is = that what you are basing this on? Do you know of any implementations of = this I=E2=80=99d be able to test against? Regarding attributes, I know that PKCS#8 defines a way to include = optional attributes in the PrivateKeyInfo structure, and that a list of = possible attributes is defined in PKCS#9, but I don=E2=80=99t believe = I=E2=80=99ve ever seen the attributes field used in any PKCS#8 private = keys I=E2=80=99ve ever run across, or any options in tools like = ssh-keygen or openssl to set them. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_49EA0333-48D5-4D77-98BB-0F41FDBBC8DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian Smith wrote:
I've= been creating some test vectors for Ed25519 and X25519 PKCS#8
files, some of which I've already shared on this list. I = would like to
create some test vectors that include = attributes, but I've not seen
any. If somebody = could share an example of a valid PKCS#8 file with
attributes, especially ones that make sense for PKCS#8, that = would be
very helpful.

I support Ed25519 keys in AsyncSSH right = now, but only in OpenSSH key format. I wasn=E2=80=99t aware that there = was a PKCS#8 representation defined for these keys. Do you have a = reference you can point at for that? I=E2=80=99d love to support it if a = standard exists for it.

In a search, I just ran across https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 = =E2=80=94 is that what you are basing this on? Do you know of any = implementations of this I=E2=80=99d be able to test against?

Regarding attributes, I = know that PKCS#8 defines a way to include optional attributes in the = PrivateKeyInfo structure, and that a list of possible attributes is = defined in PKCS#9, but I don=E2=80=99t believe I=E2=80=99ve ever seen = the attributes field used in any PKCS#8 private keys I=E2=80=99ve ever = run across, or any options in tools like ssh-keygen or openssl to set = them.
-- 
Ron = Frederick
ronf@timeheart.net



= --Apple-Mail=_49EA0333-48D5-4D77-98BB-0F41FDBBC8DB-- From nobody Thu May 11 22:27: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 14D64129B46 for ; Thu, 11 May 2017 22:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdjBIJM_lDmx for ; Thu, 11 May 2017 22:27:17 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0134.outbound.protection.outlook.com [104.47.38.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF6D129C07 for ; Thu, 11 May 2017 22:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Zd9k3TB7C7WvaXcK/faS1/NRdHk3tVXzINyY/n+zYM=; b=ituqSBQNsTQ+trCRgHYq3qlg6RLaXs/cxj4OpiBUuOuQeG/mXK6GWwe5nwE6IGwA27bxkkUYabqWqma1IhGdB0uzeqq2bNedhP744OPh9HoFgqPbmJJgTWEJJ/UfRmw2wWFJMVh+U808ZcOv3MODlfYJayv8U97jhAb0xPgHclo= Received: from BY2PR05CA033.namprd05.prod.outlook.com (10.141.250.23) by BN1PR05MB261.namprd05.prod.outlook.com (10.141.65.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 05:21:55 +0000 Received: from BY2NAM05FT043.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by BY2PR05CA033.outlook.office365.com (2a01:111:e400:2c5f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Fri, 12 May 2017 05:21:54 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT043.mail.protection.outlook.com (10.152.100.180) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Fri, 12 May 2017 05:21:54 +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; Thu, 11 May 2017 22:21:53 -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 v4C5LqKj019830; Thu, 11 May 2017 22:21:52 -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 5FFD611446; Thu, 11 May 2017 22:21:52 -0700 (PDT) To: Ron Frederick CC: Eric Rescorla , Brian Smith , "denis bider" , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" In-Reply-To: <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> Comments: In-reply-to: Ron Frederick message dated "Thu, 11 May 2017 19:27:30 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 May 2017 22:21:52 -0700 Message-ID: <1139.1494566512@eng-mail01.juniper.net> Sender: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(39400400002)(2980300002)(199003)(377424004)(189002)(24454002)(377454003)(9170700003)(50986999)(54356999)(2906002)(76176999)(8656002)(76506005)(53416004)(7696004)(2950100002)(6916009)(2810700001)(23676002)(229853002)(7846003)(6392003)(55016002)(478600001)(7126002)(6306002)(54906002)(93886004)(6246003)(6266002)(117636001)(53936002)(5660300001)(106466001)(305945005)(105596002)(4326008)(39060400002)(189998001)(47776003)(38730400002)(356003)(77096006)(110136004)(50466002)(86362001)(8936002)(81166006)(8746002)(8676002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB261; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT043; 1:KNsIhHSwKUiMDOxcZ+8ZBolPUrmxSQPq/wpdCIQtbk71p5fV3jcGzFfRds+NoTo6jwMDtx/jSpxpOOIkZbqE4t1tViduXqUTKz29GEq4VljdlSbDlqjP5qKU3QUiA9X0Ynuv/mTivVo+YBpP25IxDArf5Y2+ISLR7TUH7SeQx34aMsPE/jCzrqJkNjOH/ydnMenLWzsaOdOMDBgdV9qAizb54hDKL0bJ8/jUMCOHNI95L8lsYnQQJHqvk/QZ1YD7ZK/rT7Pb9dKFFNvodQ6e83YyIQYcqbvRXN2usDc+0GpohDGu1/BubBms9PjnL+UXdQV4DUfOvaDXGv922OwkGqZFHr6IRS/cq10ruLQDy60TVME+9rdCJiFJo5YUgOCwogvjn3l8AWvW0XbXCfQ3qFoVEf/CSFwqLrBoZoyjn/MwsF/wcFeyCvyBa5oz1nQ90KSNtqRwfAt3Br2BPo+EsdEIXxG0nKCoAU8/QN+EQ8wPNVWrkrE4QhR7PCDbXgl/5o6jX7d6vKZHP3eFS5M9Kd/Zfzakz4O+lcdIahpqkzp2Ujm5xLlvdTMpVy7suaNpDePKlcmUVzi9ZHMLXNCiPNmKD+uimo3rptfAZxNWDNiBUWWawOxIQcEq2S4Y8Fbi X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ff02e0a-9786-4eb8-eb0a-08d498f6cd85 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB261; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB261; 3:trmMcwRI2Y4YfvZ0h5gqWPHE2Oj2rT1l/khXk2lDpy8khhYwHpGngzXDyrEwXO7BLwLvsxRDOL9aJ7t8Rrc2NMSTym/Y0r+HoWUvu6SENeV26euiyz9rEbkUvtYHcuuciEm8/2uYtPKZSNz1QdCvr0aKfMEm7WaOv9jHmbZaQsC4bqd7vmG7kwNmfr7LqsftSfzSVLyE5W6YDTxMVKVIHdF9qEYCER8W12Y+8IKbqqjVxbdsWr8E3dGOxQ7z1ILzdES5vV8qbWmTJMfeO9KovFsrf/Qd1naGA6FhDWegPJ05zPfg6ySEghc8go2GdnK0/kYdJR7UVInbxS3MDcZNmRjcbcybPV+Ngu7cWJvGAEn4UKHzNYVwRINzC86Jn7a2FKQNGw+xpZ3XKul6oqMlLZsg68MNNjppLkXdUvmZVipGrdyfB4tlGmqw6dgqq5iFRhFjcHSqc6PBl7DDprjv0d0g15nLYkZVVUujz2q05XayS6MskgcPRbWXpj716bKP X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB261; 25:tUAKRghI84m1xhFeiApbcgwWrogI0g1hi0AO4P2ou+RnW5un1HMMg6Tmm/0c+sxEfKHz3pPwe5lAh6Oa3UyoQstXNGsWmautg1SnJIE1M/wtcMk6mZbo6V9HPmjMMJPsfleDl5YZkTTbna7wfkv2QszjNArZtLbmnYkHw4j03YrPP9kiDWMny6/zMPggBwVJIP8JS22jvOlp6E5EqhDU06wrgJher0CgVKsMOrddurzoZHel5/t2vDW2Tv5pOY86AmBWOBCZkXNrCnoY9ki340QtNwJX6vl0n3Q3B/vJ5Rh1GydGqCE8q8+jHXxbxeCRSzzU4zEr1QL63Tr8DEKKgC5Nlf59nJmiN6OmaINIZvaXhmN1ll+zE+lbyYUlwcHJ0sEbI3QYQlONr9j1F+xCs0rKIAKc8Kovcxb+KKqCloq8QfzOQj72lXxA0uMUmwBAg9bCoJxaDs8PxD6V85se4Cg2LqivYqUQ5dn30VrfxP4=; 31:0VPEs0kfAtbNcPZ6+mGVyUoidIebGvgj2BOChq6tKfxprjzajIiRi5WHCW380pQr4YqTeQsg48Dk3YrRuHfUJPlHiPON/j4Cdado3skSX7Dbt1YJe3IjX4sZGgJhcXgwRACvVvJKlVhGYZH1wzfrlGSlmd8BEYgSRncU8eFYO4SBUZpSVlNJtSpRf6QQqlQLrLhmAIpijqo74ccYaCUAHV1OjCBat0b64Qwb3a1l3DrA3rbnIZrUS7+qo1FWIzBDPK0J0iQ2Qtu3Xdpveullkg== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB261; 20:eBrenFTY+5t0m4dJQjM8vy8qVpKo8Tpr3jFaEgxRSwyZWnyaBP3Vh059FhoXZ5f6z/C9xtvW0h+rGChQ+V9nAbkT4cCl3H768RGuBo+DmT7ABySPOYQZNcGwMM/4WDWzZgLsdmHXFhFTQdBO1ta/53AuZQ2ENR16pG5SvyJZF/HEDwQIsAyGDlyAMRwiSeoTUrKKu4by36dgCAvC90OEQIuApHdEpvXjVaUD9YE7PHNSu5qS/7WYZbRMbwsHuoM1kYunMoQfU6PsK3Fom3i0Q9i3JQ7DWe5p0P2u52M1XxC+gfl9jc/wixaq/PJ3nLtJ4zloeDbeisipPrWKv6vEc5UMJRUAqB1vDQX69CrRkqdqj9gdJrV8J2lJB5Mu393wLD7GARot7m0XdqYc1CEX8WtbL/CbfZWa6dykqvIX06BCmXhsxWlMw2zOtuzPSPxN9T02vqMfknWZqLnxDl31MdFzqEW+R174kbXpfEZCv/vG2YKrHmf0EPjelRubSD9q X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(8121501046)(13023025)(13018025)(5005006)(13017025)(13015025)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(6072148); SRVR:BN1PR05MB261; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB261; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIyNjE7NDovbGVreTVsV3JpZ0lacWtXSHV3WWJaMUFENkQr?= =?utf-8?B?QUxkdmIxOUFMcUpZQjFtSjlBS1hkQVdpd0pjbHkvSkNiOUd1WkdhdllSTzBq?= =?utf-8?B?N3ArUFByVWhPZEhuOGp5YW9uTHZYbERTSFdTZ2U2RUdPWkVSR0JENjg2b2h2?= =?utf-8?B?a2hIaHJXalFHOWRERFk2TE1EeS9EV2xOd244bkhuTWl2NzJkM3VzdE5PM1NS?= =?utf-8?B?L2Q5ekQwcnNIOFhjNVA4WkltOHpJWHowNmRYWVpXSldFV1JVb29WMkx4ZEta?= =?utf-8?B?d3p4c3FYWlkzSVZBa1NCbFMybHlLbWNsOFovbVA2d0pjaVVBSGExVDNreVlX?= =?utf-8?B?aXRWT3pwMWlIcDdLQ09renBjS0NWQytieFZrYzN0OU5CWUtsR0VRV2JVdWVP?= =?utf-8?B?NExyMXdaSThYbjNuRGYzeitXM3Z3U29LVlE0MXEvbjhoVFVNSFFzam5kK3BG?= =?utf-8?B?MXhTTXhiMWlxMEtqR2M3ZXhtMEl5UVNqWVJyblhsQkdhRmVMbk5SZ2J2Y08z?= =?utf-8?B?UDFtc1R5ODhDUFhCNFo2dSs1LzdvVlpsNUVOcTRGU0Q3STlsYUxmS1dXaTlR?= =?utf-8?B?aWdYc3lpVUc0UTlwWmY4YUlQdm1GRFlvSldqekxwTzVMa3NXZFZRQ1pMMFQ5?= =?utf-8?B?T2FuSWFHRE9jZ2lFcnhrN3Jldmh3SDFRMllUNVJScjc4OHpYVFlyM3NSWFl5?= =?utf-8?B?ZVN4NWEzYVVoaWtFdGVMSzk5ZkZ5cFNIMk5Pb3g5STRwbUF4SWxPWlYrbm1U?= =?utf-8?B?TkFZbmV0Umh6TzBaYU8wWlRMR1VDWVdvNDNVRkVQclhNeW5TNktZWCt4bkZy?= =?utf-8?B?WU5PRWhZVUw2bnhSdjdCVGphOGJOUmU1VUUxZ01aVnZWSjg5VHFQTzVIQVJx?= =?utf-8?B?UjFaOU0yOWdvNkdhUFF1SldBZXlSZUY4N3JqeWtRYkxvY2h2aVJ5SjBmVTRz?= =?utf-8?B?c2pnbTdHWXBOWjlnTkladFN0WVc1MmU0SkxXWW1xN01aNjhyY0JFbEdQc0Zn?= =?utf-8?B?NXV6aFAwU0x5TmI4R2pQUVM4eHN1VTFJY1RDZDl0M25uM2VSTHdaZVErWU56?= =?utf-8?B?OXhuUWp2eWdUU3YwMkFJUkJra3Zqb3JOYktERkx5Z3NGM3liTkorOE84Ymgw?= =?utf-8?B?eW9uMWNFU0sva1FPcXFBNTFHeitSVTZkZnBmZ2NtVDV1azI2ZU0xMUdzMTAr?= =?utf-8?B?aTlobTNXd1R0aDZqdUxCdW52TWZQZkpheUtqWWdQQnZBS25WckZSMkh6YnFk?= =?utf-8?B?MHNDT0VqeEhxeS9HTVdrZkFMcS9vK21MVFRVZWk5YVJsaVVyck5DdStwZ2tl?= =?utf-8?B?c0VIZzFSeFF3PT0=?= X-Forefront-PRVS: 0305463112 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIyNjE7MjM6bkNpMW00L2J6NEVTaldKZEVTR3ljYzI5RnJj?= =?utf-8?B?QXlEbXQyS3dONWZ0MmZIVFZ1aG5IMS9ZeUUyVUxLVnc5QlVCeFRKcVlSLy96?= =?utf-8?B?VTVyckRWenBrOHAva2N6YzJnV0ZLM2JjZWFSQkdyTm1sdkhxZ2NSaVNTMlBS?= =?utf-8?B?UmgzNmNFYjFUeVB0cGNPZmxKNXBib3B4amNHRTVqYVQ2Z3pBQm90emJNZm9E?= =?utf-8?B?djlaMFhod0VjMHo1QmdOdHhwamh5VnFPekc1TzFTS3VjdUIxeTRpMW1PbWhZ?= =?utf-8?B?YTZVMmxvQURoNVduTEQ2MGRVeTdGTEhuUk5SdDM1emtvVkRCLzJrZm5KQmdN?= =?utf-8?B?ZXpKclNLUy82cGVmdGlpMVliZ3ppdHhvTVNFQkU0ZmFGdDdzR1lVWkJuYmd5?= =?utf-8?B?bndQSGt6RFZHNkI4YnA3MFFNTi9oRHA0MFhHdlhuaVREcE8wZE91ZEthbUNN?= =?utf-8?B?eEl1ZHdWd2ltNGtWeUl0YVhFWEhYeGh3YVdHUzI1b1laRUROc0YxQlR1bXN0?= =?utf-8?B?S1l3aFNMUjdYcEtvMEZaYWk4Ry9wSTltaGNTd2Nwb3dUcklUUExCK05wdW0w?= =?utf-8?B?bWNJdXJkSHozSnh4bXBEdkhlTVFlWVpEa0dxSXpOUGNXYnFQeGpSMVpNbUFy?= =?utf-8?B?akkzSkEwNmhsTUszKzVpNHV2c0VwNzdYMU5tWU45LzQ1R3FhRkgyR0Q2SERP?= =?utf-8?B?UmpVd1p5NThCTjJUTHdtd2hZQkNGbllIZkZHNXpmZS8vYUZFUU8xQS91ZnJL?= =?utf-8?B?eXhjc0tnOVlJRCtmVkR6dmlwVVRxRVlQVnJJck1Wb0VkWHVINVhRUGZ3cjF3?= =?utf-8?B?N3pUa0p6NHlFc1RMazNLZlhUWUxiTlBrY2p2cGw1N1JMSEFUYkdGRm93SXVS?= =?utf-8?B?KzdDRWk0ZjNwSFJaWklwRHdseGh2Nzc2Sk1peXp0Yi9SZHhMUnErYUdMNUsv?= =?utf-8?B?WXg1VUhVNnRLYWpvcmdmWVhtNGJkdUpCUzRiZXVoUkJBY2xxZUVrVXBtQTdW?= =?utf-8?B?RUU3MnJkRHhkb0dnYzlaYUtFdW5kZmY5Y1gzU1pydzY3VkxkdnhZalNzSEdS?= =?utf-8?B?RGh1bDgycklCYVZyWU1weG9MclcrdkFGZkczQXEralpEb3pCY1U4dGZrREVK?= =?utf-8?B?MW5SOTZadU5aUHM1WDR4SHZxem1EeEIzU21jTUQ4aXE0MG5oek5BTTZDOEpn?= =?utf-8?B?QXhYYXVDU1MwN3FIMlcrM1JtNXlCWUF6bVdoR1JjUEp4RnY5Z1hnZVl2c2xU?= =?utf-8?B?TFlqN3NTcU5adGtsZkMrUWdFR3YzVHhIY1lqR0dTbnBKVjNnZHdzZ1l4SnZj?= =?utf-8?B?Vk1PM2lKY3hNVzBUajRUQ0xEZDNwdVdnRE5SejNwOG83eHpwSUZpZWNWTjc3?= =?utf-8?B?SS9iRUEyWGdtME04ZFczRllRdkdJSmNsZk1NOElGMVVpcm55VDRFai9vK1pm?= =?utf-8?B?SUkrQy8xR1VQVWNtYUt5RFpQQytVejViZ1lsdGRsczNRZG9VSlJKeEloaTZm?= =?utf-8?B?dEFxTUtTaktnaFFYd0pNQUhwVzJBNzRYODVXK2hYZ1RlaDlLdDNqbmlaNGNR?= =?utf-8?B?amowR2o0ZWxUSUl0T21qeXZXYUtkUmlwL1lkVHlHdU01OWZWUWZvVDUxajMy?= =?utf-8?B?WXBCNUtQcmx2cG5sNVpYUGovOGdwcEhLd1FOZHlRQTN6VWtNTlg3akZYMGd1?= =?utf-8?B?SHdDOEJWVkwwcVg1Q2hIRnVIN2RWL2NaMCtMdGMxSExJOFBaN09HYTlWVXNG?= =?utf-8?B?ckUrR0NZaUtBSTZYK0Fha0xFUXhYZXBleVE4WC85Qy9tUEhROE9PMXMrNzNo?= =?utf-8?B?MDNKWnBSRk9NK3ZuTDBlcE80YzF2bFgrOVl1TXJvbys3UVVDa0NJYU9rL3h5?= =?utf-8?Q?8tmFgsZqZZwuAZvsFrY2KhK9RisdSw9?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB261; 6:Q/zZowRN4lwhPfU/7kAL/5TlFYmvJS/UobE29BEFnJSvzvB6SI1ZMeMvddGFq9VD1OcuhRk2DOB9hSLRLTzxKADUFqkepqYH5BVzaTpwMQyoyxd0byvk1uVq+js3C88AeO6dTax2TVXBqiRIhrYpEMx8akR9Xj5qiBSfwci+rVV3BJ+OCoQdXqNUoIWxqtoFlu2zAzqSXlwfKxoJgV1aMVF01Yhz1aBTtc6tYedFJaNMbE2akkyXX8u3v8DaYPXY/XkXftX/o80K7IGC13+KG7Lgcx27qMM+vbBBLdxHDu/II1ykS5XdkURXc81Ulci/1H2odpG7Rk+aCKC60l05ShcwtdVgSpAqVXtx7/AomBLsP0YB8U1DQf+/blFPFKJ5tJgV+a9KmhuxEENFp9hCA7mUPyaq8DT9MUzp04sPBky14tLsxwpOvZVUJunV4H5OoLy4p01MUc5kjyn/wxPpwFjeRHOL8+W6X9BsgrcSmliecnLGN7zuTuyGi155uJnzdkFdAhrpualyRrAZAr9QaFmK4uC/U06y56GkmHv6Ghg=; 5:RbdNLjPLFPPpqrXP5yqWSYii+VgsOZroFglcWfJMB7BWAZecO1o/Y2byLkonsnI+1CTo9GRfs8iyfHa5jpnPPzLaDhDo7o0Yg+igdlgsqtgnOeiVBxWlS/LsRiGVtvPtRPkKPHopOIJ7eg5i7cE4+w==; 24:H1niofDoP8YRVAxK9t136KPGQhPlK+pP7IEQaaZW4KpG9OxB9Pzp1k2pnlV4XldHh7uu9fDcYRaZyrdO4goK3KGh55C43n9SdOko0tR+KlM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB261; 7:TapZbingXwEE4fnH1TvlgVj8YutQXJgdbZUjMuUJDC6V5a093BC2krun6/TUtNtLWC0dtr/N2BpLq0hASFz4LuOyAe+c0uTEZPNMyNFy2WV3OBhx6F6ZeTvQOyt1TjOoeFlx1LldASqs5rR2JRB7A9uE5XYr8D2SfRhEjkGZX9/J695bk8TgcTL2SIBradimTZIXujUZlj3qlhsPaUB2x+70rpz9pGhEJNcHLzPBWVzqA/qm020N/N8WSU6sMvraeK0WK03Bv5epapoOASgFsP/yUqg6TnC2TrJGMOvtU569AkEZQIkCZW9Hv0nuT97N2f60zwwYheLq0eJNmWr1FA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2017 05:21:54.1143 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB261 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 12 May 2017 05:27:20 -0000 Hi Ron, Ron Frederick writes: > Hi Mark, >=20 > On May 11, 2017, at 6:32 AM, Mark D. Baushke wrote: >=20 > I just took a look at the updated draft. Here=E2=80=99s a copy of the tex= t in > section 2.1 and some inline suggestions: I am always interested in making the text better. > 2.1 Shared Secret Encoding >=20 > The following step differs from [RFC5656], which uses a different > conversion. This is not intended to modify that text generally, but > only to be applicable to the scope of the mechanism described in this > document. >=20 > The shared secret, K, is defined in [RFC4253] as a multiple precision > integer (mpint). Curve25519/448 outputs a binary string X, which is >=20 > [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80= =9D. I=E2=80=99d > suggest saying =E2=80=9CThe shared secret, K, is defined in [RFC4253] as = an > integer." Section 8 of RFC 5253 actually says "It computes K =3D e^y mod p" which means that K is a multiple precision integer. As an aside, it really should end up be larger than a simple integer. Not stated, but the math works best if it is on the order of at least half the number of bits of q such that g^(xy) is greater than p which lets the mod operation do something useful. > the 32 or 56 byte point obtained by scalar multiplication of the > other side's public key and the local private key scalar. The 32 or > 56 bytes of X are converted into K by interpreting the bytes as an > unsigned fixed-length integer encoded in network byte order. This > conversion follows the normal "mpint" process as described in section > 5 of [RFC4251]. >=20 > [Ron] There are actually two conversions here, from the byte string X > to the integer K, and then from K back to a byte string to be fed to > the hash used for key generation. This text makes it sound like the > conversion from X to K should follow the =E2=80=9Cmpint=E2=80=9D conversi= on, but > that=E2=80=99s not the case.=20 True, that is confusing and should be fixed. > The sentence about how to convert X into the integer K looks good, but > I would drop the last sentence here and begin a new paragraph which > discusses the second conversion from the integer K back to a byte > string for insertion into the hash, such as: >=20 > The integer K is then fed along with other data to the key exchange > method=E2=80=99s hash function to generate encryption keys. During this > process, [RFC4253] specifies that K should be encoded as an =E2=80=9Cmp= int=E2=80=9D > as described in section 5 of [RFC4251]. This conversion may result > in a value which varies from the fixed-length byte string X as > follows: > This new paragraph can replace the next paragraph below. >=20 > To clarify a corner-case in this conversion, when X is encoded as an > mpint K, in order to calculate the exchange hash, it may vary as > follows: >=20 > o Trim all leading zero-bytes of X. If X is all zero-bytes, then > the key exchange MUST fail. >=20 > [Ron] Are you sure this is necessary?=20 Yes. > I don=E2=80=99t see any mention of this restriction in RFC 4253. If the > integer value of K is 0, it can still be encoded as a valid mpInt. It is not in RFC4253, it is in RFC4251 where it says: mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. The check for X is all zero-bytes needs to be done per RFC7748: Both now share K =3D X25519(a, X25519(b, 9)) =3D X25519(b, X25519(a, 9)) as a shared secret. Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below). ...elided... The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7). The check may be performed by ORing all the bytes together and checking whether the result is zero, as this eliminates standard side-channels in software implementations. I suppose that could be done first in linear time by oring all of the bytes without leaking side channel information... k :=3D x zbcheck :=3D 0 for byte in k: zbcheck |=3D k[byte]; assert(zbcheck > 0); while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;=20=20=20=20 which is kind of ugly... > o If the high bit of X is set, the mpint format requires a zero byte > to be prepended. >=20 > o The length of the encoded K may not be the same as the original > length of X due to trimming or prepending zero-bytes as needed for > "mpint" format. >=20 > [Ron] Actually, after doing all of this, the mpint conversion also > requires the that resulting byte string be preceded by a 4-byte > big-endian length value. So, even if the X value has no bytes removed > or prepended, it will be 4 bytes longer than it was originally. > There=E2=80=99s no mention of this length here. True, because the prepended length is not a part of the hash to the best of my recollection. Am I mistaken? > Or, as pseudo code: >=20 > k :=3D x; > while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; > assert(k.length() > 0); > if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; Hmmm... should the above use :=3D for assignments everywhere like this? k :=3D x; while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; assert(k.length() > 0); if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k; >=20 > Figure 1 >=20 > When performing the X25519 or X448 operations, the integer values > there will be encoded into byte strings by doing a fix-length > unsigned litle-endian conversion, per [RFC7748 ]. It is only later > when these byte strings are then passed to the ECDH code in SSH that > the bytes are re-interpreted as a fixed-length unsigned big-endian > integer value K, and then later that K value is encoded as a > variable-length signed "mpint" before being fed to the hash algorithm > used for key generation. >=20 > [Ron] With the changes I have proposed above, I=E2=80=99m not sure this l= ast > paragraph is needed. Alternately, I=E2=80=99d think about working some of= this > text into the two paragraphs above that discuss the conversion from X > to K and then from K to an mpint.=20 I am also not sure, but I have left it in for now. Please see my 'diff' below for the changes to see if it looks better or worse to you. > Also, =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length= =E2=80=9D. Sure, I can make that change. > I think it is better to cover this point before diving into the > details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from t= he original X > byte string. Hmmm.... here is how I have updated the text: --- draft-ietf-curdle-ssh-curves-05.xml 2017-05-11 11:58:15.000000000 -0700 +++ draft-ietf-curdle-ssh-curves-06.xml 2017-05-11 22:18:37.000000000 -0700 @@ -169,8 +169,15 @@ key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the bytes as an unsigned fixed-length integer encoded in network byte order. + + + + The integer K is then fed along with other data to the key + exchange method's hash function to generate encryption keys. This conversion follows the normal "mpint" process as - described in section 5 of . + described in section 5 of which + requires that unnecessary leading bytes with the value 0 + MUST NOT be included. =20 @@ -181,32 +188,36 @@ =20 - Trim all leading zero-bytes of X. If X is all - zero-bytes, then the key exchange MUST fail. + Trim all leading zero-bytes of X, as required in section + 5 of . If X is all + zero-bytes, then the key exchange MUST fail as required + in section 6 of . =20 - If the high bit of X is set, the mpint format requires a - zero byte to be prepended. + Given X is a positive, if the MSB of X is set, then + the "mpint" format requires a zero-byte to be prepended. =20 - The length of the encoded K may not be the same as the - original length of X due to trimming or prepending - zero-bytes as needed for "mpint" format. + The length of the "mpint" form of K may not be the same + as the original length of X due to trimming or + prepending zero-byte values as needed for "mpint" + format. =20 =20
- Or, as pseudo code: + Or, as pseudo code (without dealing with side-channel + issues): k :=3D x; - while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; + while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; assert(k.length() > 0); - if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; + if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;
@@ -214,7 +225,7 @@ When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a - fix-length unsigned litle-endian conversion, per . It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer From nobody Fri May 12 01:33: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 94892129B4C for ; Fri, 12 May 2017 01:33: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=[BAYES_20=-0.001, 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 f9JDOLIwqiMA for ; Fri, 12 May 2017 01:33:51 -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 32D38129B48 for ; Fri, 12 May 2017 01:28:25 -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=1494577706; x=1526113706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ETEr01HFnr4uu+JXAh1TlOTFR188Y4tejwk5bUBCYtk=; b=llPl86U6eUQntjOPB0Fi2RvUWqAk6XpOPfuLjczOrTU6r8fGSfEUd4sB SuA90DIp47MfiWMs1mhYpXJGqXHnMtH0MVz1b6kN0i7iYYejaqkCtubo/ 3s1P6CN2mfSE3wj/DaW8SsdCnhXYRGrH2MVRrguHH7ls65JQyO9F1p5BY mfX7KHhSX3zVrUqXe3cWVibJb8HtEMtqwmTCbYCHBvk3Irf66SY9XhoNy jdBrDuYnegJLEElUlFyLY8iIm293oclc/Gyt7SO6SNPmr6A9xG1WfalHY Vnl8NG9/Lw5s5O1mxEqIaswuY6osn7+g2L88viGini6uvuGQBysn7X300 w==; X-IronPort-AV: E=Sophos;i="5.38,328,1491220800"; d="scan'208";a="153937927" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 May 2017 20:28:21 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 May 2017 20:28:08 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Fri, 12 May 2017 20:28:08 +1200 From: Peter Gutmann To: Brian Smith CC: curdle Thread-Topic: [Curdle] Wanted: A valid PKCS#8 file with attributes Thread-Index: AQHSycWd5zgTPNs+GEO0ppgfX+m8E6Hu6gvo///btICAAZnUeg== Date: Fri, 12 May 2017 08:28:08 +0000 Message-ID: <1494577653150.28603@cs.auckland.ac.nz> References: <1494497413004.14332@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] Wanted: A valid PKCS#8 file with attributes 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, 12 May 2017 08:33:54 -0000 Brian Smith writes:=0A= =0A= >Are the attributes in the PKCS#12 part or the PKCS#8 part?=0A= =0A= The PKCS #8 part, they follow the private key components (of the RSA key).= =0A= =0A= >It seems like it would be good to find an attribute that makes sense for= =0A= >X25519 and one that makes sense for Ed25519. =0A= =0A= As I mentioned, Microsoft's version doesn't make any sense for RSA let alon= e=0A= '25519, so I guess if they did '25519 they'd set digitalSignature for X2551= 9=0A= and keyAgreement for Ed25519. "You asked for attributes, you didn't say th= ey=0A= had to be valid" :-).=0A= =0A= >The point of the test cases would be to indicate that one shouldn't reject= a=0A= >PKCS#8 document just because it contains (an) attribute(s) that one doesn'= t=0A= >process.=0A= =0A= Again, with this one it'd be not just an attribute you don't process but an= =0A= attribute you have to ignore for the key to be usable.=0A= =0A= If you really wanted a '25519 PKCS #8 with attributes, and more importantly= I=0A= guess attributes that make sense, why not generate your own? You just need= to=0A= write some arbitrary X.509 attributes after the key. No-one seems to know= =0A= what to do with them so you can probably write almost anything without it= =0A= mattering much.=0A= =0A= Peter.= From nobody Fri May 12 22:26: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 BFEA1129553 for ; Fri, 12 May 2017 22:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKS-rMCtqBxH for ; Fri, 12 May 2017 22:26:24 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 4F788126C25 for ; Fri, 12 May 2017 22:24:13 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n23so34203712pfb.2 for ; Fri, 12 May 2017 22:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cKN9oSPunz8b3EgvhWMDmgSWwDGv9uUxTewKPMi0DGg=; b=Ht5C//D6babAF7UPo9OkVU8JxmO8pKofZ8oeLhkwisw8DwP/ycKg1+9HrmJ/0+eMVp p4lO3y17fcM/UkNn33QxqqAQfcCOKr3jF/muZU/9ToTy74BIXiA+I1lf+pqGIfde5Zuj IwbpLb+H1XZsf8g0o8UzuvGnpQ1sZFfIOwKN0= 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=cKN9oSPunz8b3EgvhWMDmgSWwDGv9uUxTewKPMi0DGg=; b=muQWpan9uL3izNRSec/TFooft5uU53zOIvxTcgYWfkVVR78DqxlRJAUMXg3+nK/52U kbDA0CldwgGzSehd6RFU1mDbF9YF9g/qYJj26QlCIZ7ZQIod+Cd4hrlCj7yB6+V/IyTO SJyRgqFQ0DqX9k3YWes09EJK6fZMZ1Oc9WfZZx0qXKqaJcuMd7+aTR3LHd4aBnAGn7fa MA+Hsdkg/6Zht975YpvycoZe7YUjEjCRa4fDfOGTISCtBBfj1Gipz/puqXXaDmQD1B43 DmNJCRGPIFTrupc0q0LMJ38RbXTHbHePTnjzWm5cpGz6Ca5MU+OL2+M06ihs0WBJfeV1 oY4Q== X-Gm-Message-State: AODbwcCWPxNZbpOcbfIhl94k4Pc7MI1jl0J2VxCkiB1SbBBVSZO0bQ3D X4bYoLMfKkJYwQ== X-Received: by 10.84.142.129 with SMTP id 1mr9474087plx.3.1494653052856; Fri, 12 May 2017 22:24:12 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id y63sm8909487pfa.107.2017.05.12.22.24.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 22:24:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ron Frederick In-Reply-To: <1139.1494566512@eng-mail01.juniper.net> Date: Fri, 12 May 2017 22:24:09 -0700 Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> To: "Mark D. Baushke" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 13 May 2017 05:26:27 -0000 Hi Mark, On May 11, 2017, at 10:21 PM, Mark D. Baushke wrote: > Ron Frederick writes: >> 2.1 Shared Secret Encoding >>=20 >> The following step differs from [RFC5656], which uses a different >> conversion. This is not intended to modify that text generally, = but >> only to be applicable to the scope of the mechanism described in = this >> document. >>=20 >> The shared secret, K, is defined in [RFC4253] as a multiple = precision >> integer (mpint). Curve25519/448 outputs a binary string X, which = is >>=20 >> [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an = mpint=E2=80=9D. I=E2=80=99d >> suggest saying =E2=80=9CThe shared secret, K, is defined in [RFC4253] = as an >> integer." >=20 > Section 8 of RFC 5253 actually says "It computes K =3D e^y mod p" = which > means that K is a multiple precision integer. Section 8 is specific to the original Diffie Hellman key exchange. The = computation is different for ECDH (described in section 4 of RFC 5656), = but that states "The SSH framework requires that the shared key be an = integer.=E2=80=9D and then goes on to describe how to do the conversion = from an EC field element. For X25519, I think it makes sense to state = something similar. > As an aside, it really should end up be larger than a simple integer. > Not stated, but the math works best if it is on the order of at least > half the number of bits of q such that g^(xy) is greater than p which > lets the mod operation do something useful. I agree that in all of these cases the integer K is likely to be very = large (much larger than something which would fit in a traditional = integer value in a language like C). However, =E2=80=9Cmpint=E2=80=9D = here really is just an encoding. In Python, for example, K can be = represented as a plain Python =E2=80=9Cint=E2=80=9D type, since that = natively supports arbitrarily large integers (limited only by available = memory, I think). The =E2=80=9Cmpint=E2=80=9D conversion here actually = changes the type from an =E2=80=9Cint=E2=80=9D to a byte array, which is = needed to be able to feed the bytes to the hash function. Even in other = languages where large integers are represented as some form of an array = already, it=E2=80=99s important that the exact representation of this = integer as a byte array is specified, so that all parties compute the = hash in a consistent manner. >> o Trim all leading zero-bytes of X. If X is all zero-bytes, then >> the key exchange MUST fail. >>=20 >> [Ron] Are you sure this is necessary?=20 >=20 > Yes. >=20 >> I don=E2=80=99t see any mention of this restriction in RFC 4253. If = the >> integer value of K is 0, it can still be encoded as a valid mpInt. >=20 > It is not in RFC4253, it is in RFC4251 where it says: >=20 > mpint >=20 > Represents multiple precision integers in two's complement = format, > stored as a string, 8 bits per byte, MSB first. Negative numbers > have the value 1 as the most significant bit of the first byte of > the data partition. If the most significant bit would be set for > a positive number, the number MUST be preceded by a zero byte. > Unnecessary leading bytes with the value 0 or 255 MUST NOT be > included. The value zero MUST be stored as a string with zero > bytes of data. That does not say that 0 is an invalid value. It simply says that when = converting to an =E2=80=9Cmpint" byte array, 0 is represented by a = zero-byte array. > The check for X is all zero-bytes needs to be done per RFC7748: >=20 > Both now share K =3D X25519(a, X25519(b, 9)) =3D X25519(b, X25519(a, = 9)) > as a shared secret. Both MAY check, without leaking extra > information about the value of K, whether K is the all-zero value = and > abort if so (see below). > ...elided... > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve (see Section 7). The check may be > performed by ORing all the bytes together and checking whether the > result is zero, as this eliminates standard side-channels in = software > implementations. Ok. I still have some doubts about whether this belongs in this = specification, though, as it seems like the abort operation should be = performed by the code implementing the X25519 multiplication. Before = returning the byte array X, I would expect that code to check for an = all-zeroes result and return an error, so the code handling this value = in SSH would never even see the case where the converted value K ends up = being 0. As one data point, I checked the libsodium implementation, and it was = changed back in November of 2015 (release 1.0.7) to perform this check = and return an error if the result of the scalar multiplication ends up = being all-zeroes. I don=E2=80=99t see a specific test vector which I can = use to actually confirm that this works, though =E2=80=94 does anyone = happen to have one? >> [Ron] Actually, after doing all of this, the mpint conversion also >> requires the that resulting byte string be preceded by a 4-byte >> big-endian length value. So, even if the X value has no bytes removed >> or prepended, it will be 4 bytes longer than it was originally. >> There=E2=80=99s no mention of this length here. >=20 > True, because the prepended length is not a part of the hash to the = best > of my recollection. Am I mistaken? Yes - the fixed-size 4-byte length is always included as part of the = bytes fed to the hash. >> [Ron] With the changes I have proposed above, I=E2=80=99m not sure = this last >> paragraph is needed. Alternately, I=E2=80=99d think about working = some of this >> text into the two paragraphs above that discuss the conversion from X >> to K and then from K to an mpint.=20 >=20 > I am also not sure, but I have left it in for now. Please see my = 'diff' > below for the changes to see if it looks better or worse to you. This definitely looks better. It still needs additional text to cover = the insertion of the fixed length bytes in front of the encoded = =E2=80=9Cmpint=E2=80=9D value, though. --=20 Ron Frederick ronf@timeheart.net From nobody Sat May 13 07:53: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 2C6C11294B5 for ; Sat, 13 May 2017 07:53:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 972zBNTggs78 for ; Sat, 13 May 2017 07:53:06 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0132.outbound.protection.outlook.com [104.47.32.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44192129AC6 for ; Sat, 13 May 2017 07:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Nt4s5OKzzwQ71fR8G+9+q2tRSH9P0ZPmcF3bBDgeAg=; b=I27Yhj5XxadSpJPzTBLY+ARRpsc+PvocwK4JvtCEgEIt7I5ayLdSI+urhiYfRLEKd9h3kH/9xmblRgtFJj5a39Fq/uKZ+1mCapY0pPzQxY9iG6J1yQDIsIqhJOZDu86flrG3Oa1hvpBcRQG/GOubJioUQcMpIPdmW8Wbaz1Y/4s= Received: from CO2PR05CA026.namprd05.prod.outlook.com (10.141.241.154) by BY1PR0501MB1303.namprd05.prod.outlook.com (10.160.200.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Sat, 13 May 2017 14:51:07 +0000 Received: from DM3NAM05FT063.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::201) by CO2PR05CA026.outlook.office365.com (2a01:111:e400:1429::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5 via Frontend Transport; Sat, 13 May 2017 14:51:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) 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.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT063.mail.protection.outlook.com (10.152.98.182) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Sat, 13 May 2017 14:51:06 +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, 13 May 2017 07:51:05 -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 v4DEp3rP013222; Sat, 13 May 2017 07:51:03 -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 CFEA51145A; Sat, 13 May 2017 07:51:02 -0700 (PDT) To: Ron Frederick CC: Eric Rescorla , Brian Smith , "denis bider" , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" In-Reply-To: <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> Comments: In-reply-to: Ron Frederick message dated "Fri, 12 May 2017 22:24:09 -0700." From: "Mark D. Baushke" Date: Sat, 13 May 2017 07:51:02 -0700 Message-ID: <74670.1494687062@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39850400002)(39400400002)(39840400002)(2980300002)(377424004)(189002)(199003)(9170700003)(54906002)(86362001)(48376002)(39060400002)(8676002)(6266002)(5003940100001)(305945005)(106466001)(55016002)(76176999)(356003)(189998001)(7126002)(5660300001)(8656002)(81166006)(50466002)(76506005)(2810700001)(7846003)(50986999)(6392003)(53416004)(105596002)(4326008)(93886004)(2950100002)(6246003)(117636001)(54356999)(47776003)(77096006)(478600001)(6916009)(97736004)(110136004)(7696004)(2906002)(53936002)(38730400002)(229853002)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1303; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT063; 1:kK19z7hpP2CdR7cyrLI/gaS/Fqq1IBoedKLbbQJdgdu5VYSFMigv439MaKfuY8WL6HCVoN1FM7qXYoU9lTS5trwcXvrX8c3uqT21qoJC6a0NH7gGSsxtL2Xrx2lQDG5JDDy26k4syPpGdICEHzTDBfhMds7fnzyKiOsFx9pogR9KwbKFCfXLn+SyS6FIuO5/TeQdTrqwxmJLhCBmrxEOAqmO8euYgpXERSL24iiV01YZzNAGQgZx4bCyCkT8ukLkjUG8qdZvK6DvImx/V9C7Bs96ZFDPcTZtC9bJP1yLCzjl5qfECJFOi6yJCHCXA6WzkdIJwJB/1F/t1KF0CsBEs8Z1A/vfe/fZOWSw5TO3gC1KYCBcL3REbG06083N1Zppx5J7VpeXWOqcbUp974wQXWs1B+QJWpMAAUod0t8/z68bK3cyRTYwlj28bJVT/lO1FlyTN6QQ3V4UbPvXGAG2oxWNB7iNF/1JETJHIkAWoHbxQRs+oVibq/0OG988g7CJe1E0psF3Mg6QsBgNTrSrLBZRbOQFOf2VOt6wqZuNsS1F8RKOPrDUNeMEDH7H+hA7p1esW5DRVA9BZwoolc7uFIQCTLrjPah2v+hQ14S4E8uuh38in2pUW7yJqfj7yCOH X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0d5f404b-5b89-41b1-84c3-08d49a0f7c45 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY1PR0501MB1303; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 3:JlhY8ih6LLGTxXxEZOF6jyKr/1/SuzS5LltERA/MqfRkeCV9IB1s1ztzOtTS9k3EvwYH5Bn46Un1y3k9HB4pV4UbIcEru0ZrRXlvF3iIaMfxynvpjuU4pTdNHUPV5Sn3rVIYsHQSYGQ8WFzMVHS7VSBGsgPQ8kkwqYYFVQeIijqvBGvJrv2rDDmyeDzfumb/ba1q5Z2bngZtUZCzOyK668KbEolKN/q2e8qYhh8DxXrANR0+WmzgoUwx9746/tdEYUYNKmfdi/QZ0SI0KaqnodHJI+RTEP3n0vw1dAIZ2pDl6abxaZA0cP+Zs/KDvAXafPEhPlw3JVR6/gQXxmgBd+P1eSsKv9lP0ZS3fLWK23GPFLVFXdpM88H6OrFQKPJH4kuYLqZ2OcpITw5U5Imc8EsZZPDUjPh/4mek2CHyJvDp7GZgG8/U9XyvAXI2OePaDS3yJv4SxhzfNMOEEy0fGw== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 25:76oreod78rHMAlhf2PiS6rS6/PLHgNnE2B2l8utDbostEfCWiBIeGGOg0JqW2yZYaSwmJ/+8FvHn0YBGzcWZ0+TpI4xul4cd5n7AMp/m6sLMx4FfZGmrk1v/upFjwfwBQ0V2JPkTjDkAvUAQqXlZTgcB9ZFfdcEex6zabawDhnm3YCsCJkl1F4A7flee5DqS/U3/MuQgVmXXpMO9VbhBa40Ev+h4DRFt736tgVglWXaNrWhAA48ts3HvsbcUNnEie2p2JIMhiBMall5povMHKnaIokvCDSHRrTSVWls0XiZB1PxugRUIggPrTH2l2xr07/rWsNotBmLVPZOVppayiazKG7kUPxkNGAUnhrHr/+ve5ePNFu44LLFsLixrD4pVE29dC+JuQZPdddCQ+fAwtiNkob/msmz6wD8fdTibeoBpl2utJ0qAQPjYQVhNmw4E6nWnI0O7uD88LN2P0JZa16eor7aOQTiHu5cnLea0ys0=; 31:vkQrD+PZH9T08+YcUDm4ZytlcruhV5gxt+RT8hk+3WoOSe81xePzkKFVQUNQ2M6VUq76rLrB64obuiNXi1ceF1yD9bbkhUz6S4m+MaCKSuZ3R+JujlvpWZ2LfEduoNvwsfpmIhMdMwHM51QQqaEqaipwgEypK9mTiuliJyqYi+xwwEUhC95kkP1jsOlrwg7jFt9B0zSYmBwPgLklm3uFWnW/dhbn9klluIkFoquXuhCwKlJJGqLNabkdqQqnN9X7zsZt2tnJi/Ky+Z5Te+DW0Q== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 20:eL8ls26IRlrJCMtS1dGdNZZU+bmw8/4eD012PMq8Q9rLUVDWNXIsEBgciClsvr6aihPHrPsNoiq8NVWzY5YnByOIkxqDrqnzr6zRHryYM9btWfc50ckPEgqH7YxryRdTky83yVKgRE1xDUFyFAIa+hEgTMIDdWDzZasW7J/Hxf02qufA7wKtdEaYymc99ESVt2S1ERRwo0M2DUIz/SEe4jE9LPhoQpPqkQCfC9D9vR7WB0/U1YpTtFrJYz3mYmqWQH9ox9Z5sKrQXBKJUFpp2TgOP/up0694zlvaPHyUG1BM5myGWBrf3ar6rIBaCg/TGyrnIpykcj6qEMq4S4uuzJknuT5HaGg3nVIrznyqCPnwUI9Wg+hh9x8nS6b2B02qD5Swozkyd4hDplgzVnkiw+3ekgn0JAt0OE4RlU2wF9tvWHtJt7+9T7CzGMpQnz9K29IMiE1mCDMMCJKJ/owcMjmUSisI6WxKjUk5fmCh3Aiq2Z2pmA5Ht5qTY1ovlR3x X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13023025)(13024025)(13018025)(5005006)(13017025)(8121501046)(13015025)(10201501046)(100000703036)(100105400095)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:BY1PR0501MB1303; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:BY1PR0501MB1303; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1303; 4:I1gJWjc0uGm8iDtG6ehfxB82QmJ1wpU4vaJRKV7u?= =?us-ascii?Q?4WFbUZHvyDoFB/ha4JlUZ9FA7m4qNm/NdrqLkhmliMuyadonhXRwVIO3HE5J?= =?us-ascii?Q?JmWNZQY10NbwuqHGf7+Wio9dJy/g9m5eBX7sOnOZ8qVKl2BrfteuKYU+VpzE?= =?us-ascii?Q?f4aNga+DmcCKeZRxOc7F1Vk2PR4FS6HN235zbfPTpwWQYKAYtO4wawlI9zNv?= =?us-ascii?Q?z54gEpLXeSGSgVsHuSxLtwCyA4ZjO8yMxynF6bEA6pBEQJP1gmb1jTnxgw3C?= =?us-ascii?Q?tBHWBq2ZfNJCwpWf8vORyOwSpMscGiLnw0sgJQrYICdjUUzcORDyrCmCxdMB?= =?us-ascii?Q?vSYv0k940Ofwn4l1E57QIILgY4hoU8lDdbYPclBoVe2AHtTMSpbHPucmbVnX?= =?us-ascii?Q?UX7NslpZhSz1r+wnbqeOFTcJIhdzV716FpdFiPGf7r+5De6if5JMb8IF4X2n?= =?us-ascii?Q?5C0PCGpzBvjSCpHEQOd9OKtNeN6l4BcuTbjBDTiBZnmVp5M5xp/BQK+wM9Nl?= =?us-ascii?Q?sth9YysjApRt1luJ9AeIwyX4qxkNtS3W1pds1hCinQTJmQFOoNg8C/n8/2DB?= =?us-ascii?Q?axKLYFzPWLAQNMk9zxDzN2ybjB84bfCO1gBfDw9nRsVcj6mpYDttabVmLWFH?= =?us-ascii?Q?ArAGh98CDZyKpYjM6vO7nGLvAldaFXZXBIujvNNu3u55qYuHTPlXHLd78beo?= =?us-ascii?Q?Wf+6CFoa5QhD6NSQwcVp6whpPZNKneR8cCmoeaRWzcgA/3tOfydVfBzerDvG?= =?us-ascii?Q?wTGaPwOZkxqBEN480DO8moZAMp5oVc6yCm9abG6T3zM8c5lEplxWjJIxftw0?= =?us-ascii?Q?2KOiRCRjhKn9wHPs9SxCdKv12l8Rd9MpB9vSajyPIe3gN9+PzL6Uant3dEhU?= =?us-ascii?Q?ONVhChz4M6HqjSUwHDQn95deqX81Noa6wSZyFWIukM13meE0AfrFVp1rvIVz?= =?us-ascii?Q?NNxuv8cUP34kjiR2PfDrSES895UDoaPDZOA/mXhHlAOMs47V+B2f/NlspDit?= =?us-ascii?Q?fSjOAgUpyP+jy6LhdOimF7V7jIPG4lwh0DYJkFPtwlMzPILt0s7DOIUFto5p?= =?us-ascii?Q?ysFPOPGprn5YhQwtHHJllGIiDvi+KRlAY/R/xlaHPD53nJdJKSNhvGiCbW4G?= =?us-ascii?Q?r9WAKNLhS0CWjPfXBcdhOCTSso3yj8E9xWvVwGHvabJm8j7qloL97fKLl2OA?= =?us-ascii?Q?5z4pCDKp0usoKgJxFzNKRTJx+RZFR1r39B/0kb3/jcVb6LzYBSkwQ+rrDICn?= =?us-ascii?Q?aE0fUd+Oejo02tUXkWg=3D?= X-Forefront-PRVS: 0306EE2ED4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1303; 23:rxPzcEyyZX08EgfqHgbpyOXHAhmN1pJV9KeTyCz?= =?us-ascii?Q?p9ANKMTgFzgx13+NPO5HMFzkyTQAg11+COS13qvtYKjalzs9VcBMP1LTsflo?= =?us-ascii?Q?LQ+a8VtfjPxDErND8sCUgUnZoIZP48MtK0iy9UcSItDAQIzyvXu8P443cGY2?= =?us-ascii?Q?uPAU8K1Zpy4HvxCpEJMN7VMtKh40stFtymH+7C8nAalNDGh749KMHtlhEeoe?= =?us-ascii?Q?x33zO+FlR/QbUTr4C6IKFFvt6QT36B0flWigrlfyGYcoNvwmHH7vheXXTNEU?= =?us-ascii?Q?5B7CXXKf+LEyFo0+I4+To6pbenm2+pe95ywpVeHnRNBBSLtP7JQNFQ0bWM+C?= =?us-ascii?Q?E/sMQ22wP5cmoxOY8z8HGkG/6cna1ePliXXhCVryoa4Z2VfMTL4PmOtJbcFz?= =?us-ascii?Q?Frs+PHnX5NJZkA1q0l7gxpaUif/wkF2zjWAk7exEV0BqVfWh9ZI7oHaouTik?= =?us-ascii?Q?VkdUTqZVy1NoB3XOuFYq93VqxrF55hJcrR2IqxhcOVc5FOUAsVS37/MijTI1?= =?us-ascii?Q?/If/3Dg7uQnlev7WRG55WOoy7mUvNqwiizv+RMaLhWM6Z4QQTzGXic1FpWc8?= =?us-ascii?Q?f53SRmbsME9+1P80kdefKq+XX28B/HWd+wvLar0jZdPQ8a2TdGEMRZi3Xhbo?= =?us-ascii?Q?6+hJhczcHwnLSCZqrxm+lhx3qLOycpqcBhgJteeAVTA6G7i1zHyi77tra2Cq?= =?us-ascii?Q?dJY4bwHCmounmXA/s0weRqO25CFIixqNAnDI2p2XgS6n6eQ5jc3e7AomuyIe?= =?us-ascii?Q?a2OfveOTsMlTtvi0L55eMrKU8hvKdljCQ9in/G4ZpCyeGvN+solV20XUm6r7?= =?us-ascii?Q?3kySfqdslpx8LmaxGVt9270Rcehi5Oj/Efz4aMsxKFKn4f13TFqgrhip2v7D?= =?us-ascii?Q?PeH/uHJRMtQqJEH6lMsObAJ0yF0RMOvxogTo6V3YbE3Woi8zhr5BXNUy7sGx?= =?us-ascii?Q?bf17YvsE0rZ1uvHIgk/jo95F64nRb4qBOxcdNyoR0CeTa2HTQbnkF97TOl2D?= =?us-ascii?Q?nLkkEeO1beegOfhXJSjRfbKwP0uQ2UKWE5AkOk+o7QgTSN8tZoTq4vt4Fp8/?= =?us-ascii?Q?8B0DcwEvEYfKx9TizQeb1Ki1/wmVyU023PGOlYaWJ+qq9jMHoixKpMaEFHhd?= =?us-ascii?Q?kvKKHQVk+PvBWUvh7c8D+pgglr/CMaWFqJ2CHowMdfUQM15wr3itTP4pFgBt?= =?us-ascii?Q?cBmzIUmrQ/zxX5hhd6tH4Cdhb/cxko8jqri3zybMA17PUXjQ4/+bnxDNEWpA?= =?us-ascii?Q?2XwGJfXvnRK3XfNakl5cOv0ASk220Swx6EmeUsK4CD5yjJfx6kxqxkpHUT71?= =?us-ascii?Q?W7ygMKdp9meaoYVNImOPUIvP8q67gbtU6B8DLMkcqu4t2nCcvBskIEsJwq7E?= =?us-ascii?Q?p4Cg6TAXe6RsBsP3toU7aL4CZJYU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 6:qDDTJzn5O7GYbcpRMdqFtIFeRqDSwrngdBlq/dG0oRhnZC9Ls+9JJuBdnDds50z4bbPCP+CfgtPIwdfZEjlpJJxZef2OeVEae1kNLeeoWM/9kupUqwfKdxW85V+Ywh6HFbDCoy8KV5mcTYltHImAN2HCPwrtQNDM5J6IqYSBVHw7XaWMxdODTMwPl/I/jyhupgqoKJB4j8XhDSpL8xQfsD+a4dkPDPUxu6ODa6JGQjxAtZOWcOIGQFPM9VkK77UmIf3WZzWrovf/hJfVLI8NEwookHMHzeGepgbm7c0F5pCNeMzWF6EFtVSeYVh3Rg9+2YcOxWBmid8GDqKJseOxswDid+k1xwD7+EcFP4g+OKzbLKiXMwEtO4Bhwm1tUx2iTdO+JgxKQgSI2OKCUbnvd2Cc2Al9AnZ10v2dXn5T3m3PlJB23iFXl27oEpRPMnC2zjiyTs+CrJt7ShgkXfwaebxFtO1+SgtUJYydhqskmyoziDJeL4IgHkFJBLC5rcj/wU0ZngGjdA9g6SrvolJaqWOxlUNfwDv5FlKGGKyEoeE= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 5:6ssisPHO4++mnalbJMwj/gcIHk7lrzdV6EKdffPVQYNs1OaTVabJLwK+8MMGMJ5yWsRKdzgFRRB00fEn1Oe9j6e63o2IkeFkzrX4uyJDB2ka/8FFMhBAq9DbYHyWnFkEAJqU3BJ8w4I5vjIYyra7wr+eu1WWya15ujNmhuESLmD0FiECSeJRWbP7wFnCCLqPwvgNCQIaLFnjYwATXVX5oGTEhGIp3TDdV7CAyRifoqIhXdpBPCuHJodcatS3sjLZCQlqf33Eh87FRqciozctpscbp2TCjxMQKPdqZh/HRzJTKSfyKJzUL0kPqgPw8w/h/X+04+4MXLzd/k9gwiE1NFcJQSsZ/yWrxTsY75CZ32k8M74jk89SMNCBF2E9ZRdaQUeRZUVR6dMPxqRD6h8ehBoTvt0ucb6/D9Wtf5T8/beUUD2lwyy5gt/e4uBqr0xvYhJgS4/9jJ+NlIHR0wlmzmR3I36V+iEAghTRBmETM0PhGMb0mBHRFKy4J3OZuTPc; 24:rcjb7i8ZX2aAbFR9fyW+ndD0OpCjv6RY3Xp+InR21U1slec7X12q+pAM0hAhZeEBbu1RKIpc1hvv4dtbmh6dG4CCTOI/Ibzs5IRTGOGN2bM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1303; 7:QG43vi8ArBJ/xZsSzCLDs7OjtsgboqMi78RBvfTlTslGWZZCs1NuzhDA47EsvhQ8FzaU2/I+Hm3kF0Wn71IwG9IsAD3WpFT8waOBx76UrBH4TPp6kgq4JAuAJB7qycosY4ARAHdY6Q1wwwZMHteemeJ/x67jMxUWrYniwy6qG4hx7Q96CKmHGRiNZXNX7e52j/g3+bkFGYKcMz3RS81ZiYfO5P+bRuy8VKogtbcPqmRNzI7p57NK0S0VgNHCfzvWx8Kb49Uzk7kYEDoMk75si+kFRK9ZamWrYKjvdis8DsM1+z4gbTZxkXD2Q/RXF3Oum3Pnajpg4u4RWa2lNMkAyg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2017 14:51:06.2757 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1303 Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 13 May 2017 14:53:08 -0000 Hi Ron, I have made some adjustments. Here is a unified diff of the relevant changes to the .txt form of the draft. If the pseudo-code looks bad, let me know if I should just remove it or not. --- draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 11:58:23.000000000 -0700 +++ draft-ietf-curdle-ssh-curves-06.txt 2017-05-13 07:46:54.000000000 -0700 @@ -140,47 +140,64 @@ only to be applicable to the scope of the mechanism described in this document. - The shared secret, K, is defined in [RFC4253] as a multiple precision - integer (mpint). Curve25519/448 outputs a binary string X, which is - the 32 or 56 byte point obtained by scalar multiplication of the - other side's public key and the local private key scalar. The 32 or - 56 bytes of X are converted into K by interpreting the bytes as an - unsigned fixed-length integer encoded in network byte order. This - conversion follows the normal "mpint" process as described in section - 5 of [RFC4251]. + The shared secret, K, is defined in [RFC4253] and [RFC5656] as an + integer encoded as a multiple precision integer (mpint). + Curve25519/448 outputs a binary string X, which is the 32 or 56 byte + point obtained by scalar multiplication of the other side's public + key and the local private key scalar. The 32 or 56 bytes of X are + converted into K by interpreting the octets as an unsigned fixed- + length integer encoded in network byte order. + + The fixed-length integer is then minimized into the minimum number of + octets to represent a positve mpint. This conversion follows the + normal "mpint" process as described in section 5 of [RFC4251] which + requires that unnecessary leading bytes with the value 0 MUST NOT be + included. The length of the integer is then prepended with a 4 octet + big-endian integer which is the length in octets of the minimized K. + + The mpint K is then fed along with other data to the key exchange + method's hash function to generate encryption keys. To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: - o Trim all leading zero-bytes of X. If X is all zero-bytes, then - the key exchange MUST fail. - - o If the high bit of X is set, the mpint format requires a zero byte - to be prepended. - - o The length of the encoded K may not be the same as the original - length of X due to trimming or prepending zero-bytes as needed for - "mpint" format. - Or, as pseudo code: + o Trim all leading zero-bytes of X, as required in section 5 of + [RFC4251]. If X is all zero-bytes, then the key exchange MUST + fail as required in section 6 of [RFC7748]. + + o Given X is a positive, if the MSB of X is set, then the "mpint" + format requires a zero-byte to be prepended. + + o The length of the "mpint" form of K may not be the same as the + original length of X due to trimming or prepending zero-byte + values as needed for "mpint" format. prepend K with the big-endian + number of octets for the length of K. + + Or, as pseudo code (without dealing with side-channel issues): k := x; - while (k.length() > 0 && k[0] == 0) k = k[1:]; + while (k.length() > 0 && k[0] == 0) k := k[1:]; assert(k.length() > 0); - if 0 != (k[0] & 0x80) k = '\0' .. k; + if 0 != (k[0] & 0x80) k := '\0' .. k; + l[0] := k.lengh() >> 24; + l[1] := (k.lengh() >> 16) & 0xff; + l[2] := (k.lengh() >> 8) & 0xff; + l[3] := k.lengh() & 0xff; + k := l .. k; Figure 1 When performing the X25519 or X448 operations, the integer values - there will be encoded into byte strings by doing a fix-length + there will be encoded into byte strings by doing a fixed-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian From nobody Sun May 14 08:28: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 BDEC312932A for ; Sun, 14 May 2017 08:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 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_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mp6qKR5Ctk9 for ; Sun, 14 May 2017 08:28:46 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5827D126E01 for ; Sun, 14 May 2017 08:27:17 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u28so49094079pgn.1 for ; Sun, 14 May 2017 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m6rRm15QzwLidRjMCvmY4pK8hiF+yBPYStqSQfgQDK8=; b=Ckmi3gmcXWEaWzpGiH8cKr0BvqR9plR2unjwtoEX07pXx0HgSsoo2UWin3A6M+lHw3 CXXHpwWaB8SukeqdDn4RiLJsRfT5lSprLEEJ1QPRqnn+Wu4/9C1I6qGm4mdkOnugO5Lo L1bDfQgafPJkEDdxM/YL6CSxkJjB576P/9o7U= 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=m6rRm15QzwLidRjMCvmY4pK8hiF+yBPYStqSQfgQDK8=; b=bbos95Ba9OhB/4D5HGzPH36qFcRglZ1VwrDZ5oFQ7An6kziMRJdg/v1348Dc+UnaPv Z5FyJ1FAWSMZ/luU/QDTrPkFOOSr8getXGieV6Gkyp9z6hfwEjBLqInrkND0EEHDOGAW t8rNldQt0X0junJPn5yM+9y4u85AWa1lotutP5jdmzAiqznOnmqdfCUC6X96L+WB+UR2 WO6w3xoZzJqCGfoMsSi+0fjTyTsSY2wR9TcfPSE1yvlWAM2wk9lbYaOdHgDnnmtID26/ p0zeFppXcSpaX8WEmmhZ4weAlegf58CEil0mxkOiDHynsvmnR9m+r/Yo/FKs0+ji7voY jzWg== X-Gm-Message-State: AODbwcD6IJHJXvJzxAi1s1OoE4vbpg+Xz3UWd3d93ZYXBj+WWm1ZvCCy HJgHhN8hNCPDRw== X-Received: by 10.98.245.155 with SMTP id b27mr1807355pfm.181.1494775637137; Sun, 14 May 2017 08:27:17 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id i68sm14236597pfi.72.2017.05.14.08.27.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 08:27:16 -0700 (PDT) From: Ron Frederick Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 14 May 2017 08:27:14 -0700 In-Reply-To: <74670.1494687062@eng-mail01.juniper.net> Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: "Mark D. Baushke" References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> <74670.1494687062@eng-mail01.juniper.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] ssh-ed25519 implementations 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, 14 May 2017 15:28:48 -0000 --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, On May 13, 2017, at 7:51 AM, Mark D. Baushke wrote: > I have made some adjustments. Here is a unified diff of the relevant > changes to the .txt form of the draft. If the pseudo-code looks bad, > let me know if I should just remove it or not. I would lean toward removing the pseudo-code, and just letting RFC 4251 = and the examples provided in section 5 there speak for themselves. If = you do that, you probably don=E2=80=99t even need to describe the = details of how to encode the length. All I was really looking for here = is a mention that the length is present after the conversion, since you = had so much detail about the conversion of the integer itself. However, = if you just reference this encoding mechanism you may be fine without = it. You could replace the second and third paragraphs below with: The integer K is then encoded as an mpint using the process described in = section 5 of [RFC451] and the resulting bytes are fed as described in = [RFC4253] to the key exchange method=E2=80=99s hash function to generate = encryption keys. > --- draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 = 11:58:23.000000000 -0700 > +++ draft-ietf-curdle-ssh-curves-06.txt 2017-05-13 = 07:46:54.000000000 -0700 > @@ -140,47 +140,64 @@ > only to be applicable to the scope of the mechanism described in = this > document. >=20 > - The shared secret, K, is defined in [RFC4253] as a multiple = precision > - integer (mpint). Curve25519/448 outputs a binary string X, which = is > - the 32 or 56 byte point obtained by scalar multiplication of the > - other side's public key and the local private key scalar. The 32 = or > - 56 bytes of X are converted into K by interpreting the bytes as an > - unsigned fixed-length integer encoded in network byte order. This > - conversion follows the normal "mpint" process as described in = section > - 5 of [RFC4251]. > + The shared secret, K, is defined in [RFC4253] and [RFC5656] as an > + integer encoded as a multiple precision integer (mpint). > + Curve25519/448 outputs a binary string X, which is the 32 or 56 = byte > + point obtained by scalar multiplication of the other side's public > + key and the local private key scalar. The 32 or 56 bytes of X are > + converted into K by interpreting the octets as an unsigned fixed- > + length integer encoded in network byte order. > + > + The fixed-length integer is then minimized into the minimum number = of > + octets to represent a positve mpint. This conversion follows the > + normal "mpint" process as described in section 5 of [RFC4251] = which > + requires that unnecessary leading bytes with the value 0 MUST NOT = be > + included. The length of the integer is then prepended with a 4 = octet > + big-endian integer which is the length in octets of the minimized = K. > + > + The mpint K is then fed along with other data to the key exchange > + method's hash function to generate encryption keys. >=20 > To clarify a corner-case in this conversion, when X is encoded as = an > mpint K, in order to calculate the exchange hash, it may vary as > follows: >=20 > - o Trim all leading zero-bytes of X. If X is all zero-bytes, then > - the key exchange MUST fail. > - > - o If the high bit of X is set, the mpint format requires a zero = byte > - to be prepended. > - > - o The length of the encoded K may not be the same as the original > - length of X due to trimming or prepending zero-bytes as needed = for > - "mpint" format. >=20 > - Or, as pseudo code: > + o Trim all leading zero-bytes of X, as required in section 5 of > + [RFC4251]. If X is all zero-bytes, then the key exchange MUST > + fail as required in section 6 of [RFC7748]. > + > + o Given X is a positive, if the MSB of X is set, then the "mpint" > + format requires a zero-byte to be prepended. > + > + o The length of the "mpint" form of K may not be the same as the > + original length of X due to trimming or prepending zero-byte > + values as needed for "mpint" format. prepend K with the = big-endian > + number of octets for the length of K. > + > + Or, as pseudo code (without dealing with side-channel issues): >=20 > k :=3D x; > - while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; > + while (k.length() > 0 && k[0] =3D=3D 0) k :=3D = k[1:]; > assert(k.length() > 0); > - if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; > + if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k; > + l[0] :=3D k.lengh() >> 24; > + l[1] :=3D (k.lengh() >> 16) & 0xff; > + l[2] :=3D (k.lengh() >> 8) & 0xff; > + l[3] :=3D k.lengh() & 0xff; > + k :=3D l .. k; >=20 > Figure 1 >=20 > When performing the X25519 or X448 operations, the integer values > - there will be encoded into byte strings by doing a fix-length > + there will be encoded into byte strings by doing a fixed-length > unsigned litle-endian conversion, per [RFC7748]. It is only later > when these byte strings are then passed to the ECDH code in SSH = that > the bytes are re-interpreted as a fixed-length unsigned big-endian --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mark,

On= May 13, 2017, at 7:51 AM, Mark D. Baushke <mdb@juniper.net> = wrote:
I have = made some adjustments. Here is a unified diff of the relevant
changes to the .txt form of = the draft. If the pseudo-code looks bad,
let me know if I = should just remove it or not.

I = would lean toward removing the pseudo-code, and just letting RFC 4251 = and the examples provided in section 5 there speak for themselves. If = you do that, you probably don=E2=80=99t even need to describe the = details of how to encode the length. All I was really looking for here = is a mention that the length is present after the conversion, since you = had so much detail about the conversion of the integer itself. However, = if you just reference this encoding mechanism you may be fine without = it. You could replace the second and third paragraphs below = with:

The integer K is then encoded as an mpint using the = process described in section 5 of [RFC451] and the resulting bytes are = fed as described in [RFC4253] to the key exchange method=E2=80=99s hash = function to generate encryption keys.


--- = draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 11:58:23.000000000 = -0700
+++ draft-ietf-curdle-ssh-curves-06.txt = 2017-05-13 07:46:54.000000000 -0700
@@ -140,47 = +140,64 @@
   only to be applicable to the = scope of the mechanism described in this
=    document.

- =   The shared secret, K, is defined in [RFC4253] as a multiple = precision
-   integer (mpint). =  Curve25519/448 outputs a binary string X, which is
- =   the 32 or 56 byte point obtained by scalar multiplication of = the
-   other side's public key and the local = private key scalar.  The 32 or
-   56 bytes = of X are converted into K by interpreting the bytes as an
- =   unsigned fixed-length integer encoded in network byte order. =  This
-   conversion follows the normal = "mpint" process as described in section
-   5 of = [RFC4251].
+   The shared secret, K, is defined = in [RFC4253] and [RFC5656] as an
+   integer = encoded as a multiple precision integer (mpint).
+ =   Curve25519/448 outputs a binary string X, which is the 32 or = 56 byte
+   point obtained by scalar = multiplication of the other side's public
+ =   key and the local private key scalar.  The 32 or 56 = bytes of X are
+   converted into K by = interpreting the octets as an unsigned fixed-
+ =   length integer encoded in network byte order.
+
+   The fixed-length integer is = then minimized into the minimum number of
+ =   octets to represent a positve mpint.  This conversion = follows the
+   normal "mpint" process as = described in section 5 of [RFC4251] which
+ =   requires that unnecessary leading bytes with the value 0 = MUST NOT be
+   included.  The length of = the integer is then prepended with a 4 octet
+ =   big-endian integer which is the length in octets of the = minimized K.
+
+   The mpint K is = then fed along with other data to the key exchange
+ =   method's hash function to generate encryption keys.

   To clarify a corner-case in = this conversion, when X is encoded as an
=    mpint K, in order to calculate the exchange hash, it = may vary as
   follows:

-   o  Trim all leading zero-bytes of X. =  If X is all zero-bytes, then
- =      the key exchange MUST fail.
-
-   o  If the high bit of X is = set, the mpint format requires a zero byte
- =      to be prepended.
-
-   o  The length of the encoded K may not be = the same as the original
- =      length of X due to trimming or prepending = zero-bytes as needed for
- =      "mpint" format.

-   Or, as pseudo code:
+ =   o  Trim all leading zero-bytes of X, as required in = section 5 of
+      [RFC4251]. =  If X is all zero-bytes, then the key exchange MUST
+ =      fail as required in section 6 of = [RFC7748].
+
+   o  Given X = is a positive, if the MSB of X is set, then the "mpint"
+ =      format requires a zero-byte to be = prepended.
+
+   o  The = length of the "mpint" form of K may not be the same as the
+=      original length of X due to trimming or = prepending zero-byte
+ =      values as needed for "mpint" format. = prepend K with the big-endian
+ =      number of octets for the length of K.
+
+   Or, as pseudo code (without = dealing with side-channel issues):

=             &n= bsp;    k :=3D x;
- =             &n= bsp;   while (k.length() > 0 && k[0] =3D=3D 0) = k =3D k[1:];
+ =             &n= bsp;   while (k.length() > 0 && k[0] =3D=3D 0) = k :=3D k[1:];
=             &n= bsp;    assert(k.length() > 0);
- =             &n= bsp;   if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k;
+ =             &n= bsp;   if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;
+ =             &n= bsp;   l[0] :=3D k.lengh() >> 24;
+ =             &n= bsp;   l[1] :=3D (k.lengh() >> 16) & 0xff;
+ =             &n= bsp;   l[2] :=3D (k.lengh() >> 8) & 0xff;
+ =             &n= bsp;   l[3] :=3D k.lengh() & 0xff;
+ =             &n= bsp;   k :=3D l .. k;

=             &n= bsp;           &nbs= p;        Figure 1

   When performing the X25519 = or X448 operations, the integer values
-   there = will be encoded into byte strings by doing a fix-length
+ =   there will be encoded into byte strings by doing a = fixed-length
   unsigned litle-endian = conversion, per [RFC7748].  It is only later
=    when these byte strings are then passed to the ECDH = code in SSH that
   the bytes are = re-interpreted as a fixed-length unsigned = big-endian
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8-- From nobody Sun May 14 15:19:00 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 5F571129BE6; Sun, 14 May 2017 15:18:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149480033129.2833.5147492790299118425.idtracker@ietfa.amsl.com> Date: Sun, 14 May 2017 15:18:51 -0700 Archived-At: Subject: [Curdle] Last Call: (Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 22:18:51 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 16 06:52:44 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C63129AC9 for ; Tue, 16 May 2017 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 ilS6wqczJwiH for ; Tue, 16 May 2017 06:52:42 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 E64C912EAFA for ; Tue, 16 May 2017 06:48:59 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id g49so99946692uaa.1 for ; Tue, 16 May 2017 06:48:59 -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=zsbeGcMQ8lWS7/Bl5qNe7RuxYu0HuRdB+7yo77OM+AM=; b=Lgx0WVL/P17M0df2ZVwMzEmHt+O5+riXBWG7g8RqfcIatTR0A1VxjsBDIwVS/ZRgkR UZBNyyIaaq2Be3UHgWt9Ar7QtNsJq9k1kXgtQDMCbUwKOWTz9z/TpLmrNsbt30T4F6Xx ilm4RtpiBKxjqY9AILm8goU/kIcUGV6zCP9SjpaUGp5VpPsj5LPDtU5Ilzd3xI0qdTkk 9/tnrEtAGounDf6nPf+CWYq5m3WHJSjWSNP7A5TmQbP32ObETh0Mr1kEklU1c8p3eG5O rKqHRCnoXuuhySO0NJazOckJ4GqIq7xlBa6jM1/ILwLc5QWLrkNkRu0/PCI0hXtv8s0E mELA== 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=zsbeGcMQ8lWS7/Bl5qNe7RuxYu0HuRdB+7yo77OM+AM=; b=IB9iO6gujhX5/IVEoaXfQQoC92swkIjtA+hJENtDsQFRrr5RSh00CR6v7IBNyqljta Q0GToTKFaCHxbS7weU43pzvxYFv4umJT0jA05ZDyB5/uG+MDn4cDAGNn1y0ox7qojcto MSGUg5w4rD9wDAvadTlHmFcGrOu+lkX+o/hWXjqISX2jleP2a5PSov1l/Vgl/Xz67yAE yxd4DepYfGF3LVZdSUY6vM7jjukgRqIi4dn+KwsuaHJEie6op9v5xXjxW1o4YduSTmAG 4qOrMejWxYl4X5WZWUZ4DGMZITkH4NXCiA3exoxRUbr7mCC/V392xO2ausKSrKr4XrXy 854g== X-Gm-Message-State: AODbwcAnHyWrM8HPO6n7yz/IWZ0EgHCwwRbmlQERib+ObgrktJOVJpBp H1J2Ef6PUlR4xqeRR77mjHV+EESj1Vzi X-Received: by 10.25.229.69 with SMTP id c66mr3439214lfh.102.1494942539001; Tue, 16 May 2017 06:48:59 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Tue, 16 May 2017 06:48:58 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 16 May 2017 09:48:58 -0400 X-Google-Sender-Auth: N09BoikU0YwXjXYW5brrHTb9ezs Message-ID: To: Russ Housley Cc: curdle Content-Type: multipart/alternative; boundary="001a113c0cb2ff3706054fa46eb6" Archived-At: Subject: Re: [Curdle] Call for adoption draft-lvelvindron-curdle-dh-group-exchange X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 13:52:43 -0000 --001a113c0cb2ff3706054fa46eb6 Content-Type: text/plain; charset="UTF-8" Hi, None opposed adoption of the draft. The draft is adopted as a WG document. Please submit the draft as draft-ietf-curdle-ssh-dh-group-exchange-00 and update the title as well. I expect to start a WGLC soon. Yours, Daniel On Thu, Apr 27, 2017 at 5:55 PM, Russ Housley wrote: > Please change the Title and the file name to include SSH if this one is > adopted. I have no objection to adopting it, but please change the > document title and the file name to include SSH if this one is adopted. > > Russ > > > On Apr 27, 2017, at 5:48 PM, Daniel Migault > wrote: > > Hi, > > This email starts a call for adoption for the following draft. > - draft-lvelvindron-curdle-dh-group-exchange [1] > > Please provide feed backs by May 11. > > Yours, > > Daniel > > [1] https://datatracker.ietf.org/doc/draft-lvelvindron-curdle- > dh-group-exchange/ > > _______________________________________________ > 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 > > --001a113c0cb2ff3706054fa46eb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

None opposed adoption of = the draft. The draft is adopted as a WG document. Please submit the draft a= s=C2=A0 draft-ietf-curdle-ssh-dh-group-exchange-00 and update the title as = well. I expect to start a WGLC soon.

Yours,
Daniel<= br>

On Thu, = Apr 27, 2017 at 5:55 PM, Russ Housley <housley@vigilsec.com> wrote:
Please change the Title and the file name to include SSH if this one = is adopted.=C2=A0 I have no objection to adopting it, but please change the= document title and the file name to include SSH if this one is adopted.
Russ


On Apr 27, 2017, at 5:48 PM, Daniel Miga= ult <da= niel.migault@ericsson.com> wrote:

Hi,

This email starts a call for adop= tion for the following draft.
=C2=A0=C2=A0=C2=A0 - draft-lvelvindron-cu= rdle-dh-group-exchange [1]
=C2=A0=C2=A0
Please provide feed bac= ks by May 11.

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

--001a113c0cb2ff3706054fa46eb6-- From nobody Tue May 16 07:02: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 365611294FF for ; Tue, 16 May 2017 07:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFuFSAsHU5qv for ; Tue, 16 May 2017 07:02:19 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E797A129AA3 for ; Tue, 16 May 2017 06:58:00 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id m18so11729228lfj.0 for ; Tue, 16 May 2017 06:58:00 -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=FNaGj5rUvsGwhvpKSlHG6zbt/z2SpBbQYm3BDcupgYY=; b=OZ3sQsH2Hl1g8EjrUX9q+//6aHUGJzd25mvzottdxmnVeCOltVa7zbfALOe6YhIxf6 SiXekhBDOtAv4Dstpe04xiCz1XxX2foJe9Ci/YDakZVhqhrhH4XwEvkx8XSkhUWgz74I cxkYxf6MMepEe3I/HwqI9JxLjuUwvS5rSGhIvnMuMReS0N0LpMstEnTRL6IxB9kLzgal PTY+fyscySRA39D5ur2YlRpY7Xz4J8DdVk95KqB4CkAabgl9ErCSAuzTDecOGNY+4yxu JKrKJCU4MnJSeYFU9dWml0K2h6PzYW3qyi6buhBav/B5SqAnL0HjP2jtJTXgeOlkpC8B lLSA== 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=FNaGj5rUvsGwhvpKSlHG6zbt/z2SpBbQYm3BDcupgYY=; b=E0t5u9uKalOpUz6fOcVjiHc3MW2jJ3THXE4nbc3I5QyMmEuYEuvy4bsraIqDp41G6I RloifrgMQiURZJyoRlldTF8OZJas8rHCpZEHHw3FluKnSPU/4+y5nYEDfbO6cFx6ONb5 gi1mA49MkVWREmB/39i6OXKRkoGanUzjZ7d6Gr7E4WUgkes4dQWKCoEDFLPeD6dzImtS DMhvuVqzhYDZmILdHczsXMFQ0kXvZblL78tqoc0a06rnTl7tyo+x4AZ99K9wwIPRRhnb l7lso1oEVjHJKnbjOU8C7/ytokuw5KHbMaCLUXNeVm5SA/19UAeeoT00/Aab+ZTQyRJf ukeA== X-Gm-Message-State: AODbwcBJBD3s5/+VLi8gfzpPdxGqzd36144zKZMx1nYd+EK0MajrNIgQ RCuJ5dLqHOI/HbvwkwWEwKoHVUFszw== X-Received: by 10.46.81.17 with SMTP id f17mr3283845ljb.96.1494943078919; Tue, 16 May 2017 06:57:58 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Tue, 16 May 2017 06:57:58 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@eusaamb107.ericsson.se> From: Daniel Migault Date: Tue, 16 May 2017 09:57:58 -0400 X-Google-Sender-Auth: -3j_onISnO6L7QF3MWAOap8JFPo Message-ID: To: curdle Content-Type: multipart/alternative; boundary="f403045ff93c2db496054fa48f2b" Archived-At: Subject: Re: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:02:21 -0000 --f403045ff93c2db496054fa48f2b Content-Type: text/plain; charset="UTF-8" Hi, Please have a look at this very short draft so it can be moved forward. Yours, Daniel On Thu, May 4, 2017 at 9:46 AM, Daniel Migault wrote: > Hi, > > > > This emails starts a WGLC for draft-ietf-curdle-des-des-des-die-die-die > [1]. If you have any comment please provide them by May 18 on the curdle > mailing list. > > > > Yours, > > Daniel > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des- > des-die-die-die/ > > > > > > > > [image: Ericsson] > > *DANIEL MIGAULT * > Researcher > Research > > > *Ericsson* > 8500 Boulevard Decarie > H4P 2N2 Montreal, Canada > Phone +1 514 345 7900 46628 > Mobile +1 514 452 2160 <(514)%20452-2160> > daniel.migault@ericsson.com > www.ericsson.com > > > > [image: http://www.ericsson.com/current_campaign] > > > > > Legal entity: Ericsson Canada Inc., registered 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 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --f403045ff93c2db496054fa48f2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please have a look at thi= s very short draft so it can be moved forward.

Yours,
Daniel

On Thu, May 4, 2017 at 9:46 AM, Daniel Migault <daniel.migault= @ericsson.com> wrote:

Hi,

=C2=A0

This emails starts a WGLC for draft-ietf-curdle-des-= des-des-die-die-die [1]. If you have any comment please provide them b= y May 18 on the curdle mailing list.

=C2=A0

Yours,

Daniel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-di= e-die-die/

=C2=A0

=C2=A0

=C2=A0



DANIEL MIGAULT
Researcher
Research


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



3D"http://www.ericsson.com/=<= u>

=C2=A0

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


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

--f403045ff93c2db496054fa48f2b-- From nobody Tue May 16 07:06:45 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 AAC30129407; Tue, 16 May 2017 07:06:37 -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.50.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149494359754.11968.15430110000255937708@ietfa.amsl.com> Date: Tue, 16 May 2017 07:06:37 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-00.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, 16 May 2017 14:06:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Increase minimum recommended modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-00.txt Pages : 3 Date : 2017-05-12 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates RFC 4419 [RFC4419] such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-00 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 16 09:37: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 E678B12ACAF for ; Tue, 16 May 2017 09:37:16 -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 header.b=c1s8AjAU; dkim=pass (2048-bit key) header.d=augustcellars.com header.b=FauawSv7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq2CUpkeLF9v for ; Tue, 16 May 2017 09:37:15 -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 84FCE12EAAE for ; Tue, 16 May 2017 09:33:04 -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=1494952062; h=from:subject:to:date:message-id; bh=DRVBUGf6btku3Yz7MkFxs3Xq2b5tIS8zm847GUyp+Kk=; b=c1s8AjAUY6eP+xoZfuJG0b8YmGi5xzy1Ca10v4zUHoKTD3wcBh+m8YWBOPzW+mj3fraDxulgCO7 sHYZDdWzjUEQAn5mBBpcVUAY+7xRu/WkoLjVZnITuqVhx8NgDl8QbEi+h8meuYql+U5kFKo2dtI6T aitu4kG9glOswev1nA8bA3PplaByPuN7G/eIg7Do/2LNUN/jhvY8f6H3+GZSCuyWZ3l9c+hOJndi+ LBVNK7sy8fUvOw40e+XLLMQLkB56D7YsCzNiDmt/pJDOba1Ycd4KhdUHAcon8Bj9TuIJaj2RP4yF8 /EBcfunxAHE9vncz3zsysGMfiAKpm3EGJfEQ== DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494905254; h=from:subject:to:date:message-id; bh=DRVBUGf6btku3Yz7MkFxs3Xq2b5tIS8zm847GUyp+Kk=; b=FauawSv7j2KdDYHXOAZb2l+P2QEQqWcxnbG3SpO4COb58N9BkZmRk9SSzXQ8Cp4wjuw6OZpAWtR 586p+WOMvuB+LCX1FibJ889qEzj/xDJ+RYhKthbQTwa/I2oXOTVveyeA9jB9IaKhC20sDNUWxBdyV 60By9fHXUltdOzUWmby7ktQjeLReTAknDTy2MTcMcxKJDF4uShCiCwjfuqJWA/fO2ThNDk2a5/QJ7 Q5hD0p87J3alMsiK4RB2nZz82rxnUWxJy7svxMDjmE22+HfzMp4o0GWwWKwA3gw3gYJ7x7Lrg6URK PLBIf5BjRRMDmD1Gd+9ZpLXEmpJ9T5ARFtYg== 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; Mon, 15 May 2017 20:27:34 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 May 2017 20:27:28 -0700 From: Jim Schaad To: 'curdle' References: <149490358253.11951.15631933842563889766.idtracker@ietfa.amsl.com> In-Reply-To: <149490358253.11951.15631933842563889766.idtracker@ietfa.amsl.com> Date: Mon, 15 May 2017 20:16:40 -0700 Message-ID: <000601d2cdf2$d7f345f0$87d9d1d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGEDaCt1u6HL+GhF4WBWLJTXN/mQaKTykYw X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-01.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, 16 May 2017 16:37:17 -0000 I have updated the document with all of the comments that I have = received to date. Jim -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, May 15, 2017 8:00 PM To: Jim Schaad ; Rick Andrews = ; Rick Andrews Subject: New Version Notification for = draft-schaad-curdle-oid-registry-01.txt A new version of I-D, draft-schaad-curdle-oid-registry-01.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-schaad-curdle-oid-registry Revision: 01 Title: IANA Registration for Donated Symantec Website Security Object = Identifier Range Document date: 2017-05-15 Group: Individual Submission Pages: 5 URL: = https://www.ietf.org/internet-drafts/draft-schaad-curdle-oid-registry-01.= txt Status: = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ Htmlized: = https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-curdle-oid-registry-01= Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-curdle-oid-registry-01 Abstract: When the Curdle Security Working Group was chartered, a range of object identifiers was donated by Symantec Website Security for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the range of identifiers that were assigned in that donated range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. = =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. The IETF Secretariat From nobody Tue May 16 12:29: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 5EAF1129AA4 for ; Tue, 16 May 2017 12:29: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, 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 4g7JiFde2DKU for ; Tue, 16 May 2017 12:29:57 -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 7DC971293FF for ; Tue, 16 May 2017 12:25:08 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4GJM4nN003733; Tue, 16 May 2017 20:25:04 +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=seLQS1U8QHbkHft7F3Fmg12rdFvKBUxml/UVa1sr04s=; b=OLhVZBzD2u8jNgbuNhtaIC6dnlWzb5hsGYJKVRqFCXAvG3S6726acMow2b+QzSy+FgHx 6n3BfsuxCzbv8lqQudLXm8JdmBWRTlweiwwyBrBQ2r+RwxLumxzKk40IXxPqeCf4ZBrf Xjpeb3Q+mFycHHmSInqskUVYTFrXDlPtzaofyrtQpe7t0hx4bLfSSBkoosm6hnOu9FiU VaI2GEZNIl8Jz7QEuzFvNuLWD2L4RRGkjgUs4wBcPEd5+H3jiotYNNPVcUDoAbqJUcaB qd+HiifQzxMCdmwi7P/UuULtMlFhaHErkq9VahY4NCV7tJueC52shX1oQky4hw8tK7ES dQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ag091kdj4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 May 2017 20:25: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 v4GJLQjP016174; Tue, 16 May 2017 15:25:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2adwfu76yt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 May 2017 15:25:03 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 May 2017 12:25: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.1263.5; Tue, 16 May 2017 15:25: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.1263.000; Tue, 16 May 2017 15:25:01 -0400 From: "Salz, Rich" To: Daniel Migault , curdle Thread-Topic: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 Thread-Index: AdLE3Fc9euaV7RaTSFatYL2+8oh9RgJkZxMAAAMHM8A= Date: Tue, 16 May 2017 19:25:01 +0000 Message-ID: <545d74456e514a91855177e527210b2b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@eusaamb107.ericsson.se> 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.32.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160154 Archived-At: Subject: Re: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 19:29:58 -0000 U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbCwgSSBzZWUgbm8gaXNzdWVzIC0tIG1vdmUgaXQgZm9y d2FyZC4NCg0KDQo= From nobody Wed May 17 00:07: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 E15F612EA67 for ; Wed, 17 May 2017 00:07:47 -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 sMbFfwZUbCJ2 for ; Wed, 17 May 2017 00:07:45 -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 8C2D5126CD6 for ; Wed, 17 May 2017 00:04:09 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id o12so3841742iod.3 for ; Wed, 17 May 2017 00:04:09 -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=470ZZl70ixrBPb+Mvbl1WdiXCM8cP6EW6ByX/nb7jNc=; b=lrJ/1APUqsiA/l7c5t+7XF8L+N7McdsA29gfENd+ftZj6kJ3Eel7tEGmpW4QB1sPa2 uzdBrrjlpUYGYgBDR+pbnQ2UfexVzXuIVXMavzTaqKRyz3ccvLUAj0s3UJbSkHSKJOZ8 gMD+WBgyV96m2X92k7NPpoVSJUZ+/RyjWMSs3hL/o9BOHpi/SSbott220spAqoGgGLJk 962WKNrZJI7wBIoEcEeyMxeuARn7vq/hvy3ULF1AEuskX8jQlA2t1Jg1iHyidoIhEFtA ZRaRImmRbeLtfrmewwg1NOj6ttaJ7cfRUK8tskbmYXLWmlw06npRwUl84PZYssoCPs7/ bpKA== 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=470ZZl70ixrBPb+Mvbl1WdiXCM8cP6EW6ByX/nb7jNc=; b=tf3R2Io60vv4cFLWmgKV2mG9mdkVdaZDhYWtoKY7+gP5RmFWQtGBb6ABdplcsXn64m jvjpVlOceB05s6/4pT42iROyH6RScdRBzSpUFcOG1PcAHxlpLuddiLPRoxHylMeidlN3 sxiGmC1l5D0UzpfCuk3ZAkPftwdQwb0uhFaYDWLPfxhA221gAkcOWbG4e+Fjkjj4ju2e woooo0T9BEvljxA6hoYQiDBiU8NJCxlKxdiAxZZc0l/Sd2utDKwtF7LhgCknqDm5q66f TT1uoAwV6PRTAZuI1v/Q5K1trM33n7UF9Gbtk7roCu9/eE4Gv6QHQWpy+endHrnYUxS0 GNFg== X-Gm-Message-State: AODbwcDM/RkS6TdlGvUx13M9CxuSsq8+zjfWk2tcb9LI3GGMa3QnfcTD i+b0HdumOVnHewrkiSlq1LE3m7folA== X-Received: by 10.107.129.232 with SMTP id l101mr1656035ioi.194.1495004648829; Wed, 17 May 2017 00:04:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.91.100 with HTTP; Wed, 17 May 2017 00:04:08 -0700 (PDT) In-Reply-To: <545d74456e514a91855177e527210b2b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@eusaamb107.ericsson.se> <545d74456e514a91855177e527210b2b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Loganaden Velvindron Date: Wed, 17 May 2017 11:04:08 +0400 Message-ID: To: curdle@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 07:07:48 -0000 On Tue, May 16, 2017 at 11:25 PM, Salz, Rich wrote: > Speaking as an individual, I see no issues -- move it forward. > It appears there's an issue with my other email account. I'm using my gmail account meanwhile. This draft looks reasonable, and It should move forward. From nobody Wed May 17 09:00: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 9EC7612EB61 for ; Wed, 17 May 2017 08:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjzJdJgEMBxV for ; Wed, 17 May 2017 08:59:52 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3DC12EAD5 for ; Wed, 17 May 2017 08:54:06 -0700 (PDT) X-AuditID: 12074424-7b3ff700000007b5-92-591c721d614f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 90.02.01973.D127C195; Wed, 17 May 2017 11:54:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4HFs4jL014579 for ; Wed, 17 May 2017 11:54:05 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4HFs3Er009422 for ; Wed, 17 May 2017 11:54:04 -0400 From: Greg Hudson To: curdle@ietf.org Date: Wed, 17 May 2017 11:54:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUixG6nritbJBNp8HStjMXWhbOYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseXwT9aCbRwVZz58YG9gfMXWxcjJISFgIrHp9Xcgm4tDSGAx k8Tsz/ugnOOMEvNmPmCGcDqYJB52T2EGaWETUJZYv38rSxcjB4eIgLBEzwJJkLCwgIPEoZ1X WEBsFgFViUW3rrCC2LwChhIPercxQdiCEidnPgGrYRaQkDj44gXzBEbuWUhSs5CkFjAyrWKU Tcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgOAheVHYzdPd6HGAU4GJV4eCMCZCKF WBPLiitzDzFKcjApifLufyAdKcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd38OUDlvSmJlVWpR PkxKmoNFSZxXXKMxQkggPbEkNTs1tSC1CCYrw8GhJMFbWwjUKFiUmp5akZaZU4KQZuLgBBnO AzR8G0gNb3FBYm5xZjpE/hSjopQ4rwZIQgAkkVGaB9cLjlIhRutXjOJArwjzbiwAquIBRjhc 9yugwUxAg5tBPuItLklESEk1MDL8LOQXWj9fp/fI/avbuadO3fXMLV5FPDzf8vnzcx+0Np+J 2nDbIv2VJ8/lDemza1SiqtfsF7atZ5uxZa7LO9FfYjzXG3fdcd+y23zHDucH2+U+XVC7XX/2 2eKITCfhAo55Rz/YybicNaitbPXeXaqyK+i44ckdTyRM2BRsD83aLvtuY93t5euVWIozEg21 mIuKEwFhunufrQIAAA== Archived-At: Subject: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 17 May 2017 15:59:56 -0000 I have reviewed this draft and have no blocking objections. Some non-blocking, editorial notes: Interoperability concerns are listed last for RC4, but second out of three subsections for DES3. Section 5.2, "Modern encryption types such as [...] use" should have a comma before "such as" and before "use". Section 5.2, "It is also best practice when [...], to" should have a comma before "when". Also, "it is also best practice" doesn't seem right. Section 5.3, "Because [...], this means that these application servers also possess" should omit "this means that". I would also remove the parenthetical for that sentence. Section 5.4, "cross-realm situations" should perhaps be "cross-realm deployments". Section 6, in "ample justification for deprecating their use", "their" appears to refer back to "The flaws", which doesn't seem quite right. Section 6, "blocksize" should be "block size". Section 6.1, "[nfold] is known not to provide effective mixing of the input bits" is not backed up by a reference. (I don't know of a reference.) From nobody Wed May 17 16:17: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 57EEA126CC7 for ; Wed, 17 May 2017 16:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 BP-lQDIKTIzN for ; Wed, 17 May 2017 16:17:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE7124234 for ; Wed, 17 May 2017 16:17:02 -0700 (PDT) Received: from fifthhorseman.net (unknown [64.94.31.206]) by che.mayfirst.org (Postfix) with ESMTPSA id 83D5CF98C; Wed, 17 May 2017 19:17:01 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D6B5C1FF9E; Wed, 17 May 2017 19:16:35 -0400 (EDT) From: Daniel Kahn Gillmor To: Daniel Migault , curdle In-Reply-To: References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8352@eusaamb107.ericsson.se> Date: Wed, 17 May 2017 19:16:35 -0400 Message-ID: <87h90jaxbg.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Curdle] WGLC for draft-ietf-curdle-des-des-des-die-die-die-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 23:17:04 -0000 On Thu, May 4, 2017 at 9:46 AM, Daniel Migault wrote: > > This emails starts a WGLC for draft-ietf-curdle-des-des-des-die-die-die > [1]. If you have any comment please provide them by May 18 on the curdle > mailing list. > > [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ I have no issues with this draft. it is clearly written, and it should move forward. --dkg From nobody Wed May 17 19:10: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 B2BFC12947D for ; Wed, 17 May 2017 19:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq8WDhzEI2MD for ; Wed, 17 May 2017 19:10:15 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9900129470 for ; Wed, 17 May 2017 19:10:12 -0700 (PDT) X-AuditID: 12074422-573ff70000006f66-e4-591d0282818e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 44.21.28518.2820D195; Wed, 17 May 2017 22:10:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v4I2A9Om000464; Wed, 17 May 2017 22:10:10 -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 v4I2A5eZ006210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2017 22:10:08 -0400 Date: Wed, 17 May 2017 21:10:05 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: curdle@ietf.org Message-ID: <20170518021005.GK39245@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6notvMJBtpsOi0usXWhbOYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8efRb+aCKzwVPU/OMjYwzuTqYuTkkBAwkTi1rJm1i5GLQ0hg MZPEpCdzoZyNjBIfn55kg3CuMklMP/mIDaSFRUBVov/HIiYQm01ARaKh+zIziC0ioCjxbNVc FhCbWUBY4t/nVrAaYQFfiW3vbrOD2LxA61Y/Pw5UzwE01FDiwwkRiLCgxMmZT6BatSRu/HvJ BFLCLCAtsfwfB0iYU8BI4tihc6wgtqiAssTfw/dYJjAKzELSPQtJ9yyE7gWMzKsYZVNyq3Rz EzNzilOTdYuTE/PyUot0TfVyM0v0UlNKNzGCA9JFaQfjxH9ehxgFOBiVeHgjAmQihVgTy4or cw8xSnIwKYnyuv4DCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh/fARKMebklhZlVqUD5OS5mBR EucV12iMEBJITyxJzU5NLUgtgsnKcHAoSfCaMMpGCgkWpaanVqRl5pQgpJk4OEGG8wANLwap 4S0uSMwtzkyHyJ9iVJQS5/3AAJQQAElklObB9YIShkT2/ppXjOJArwjz1oO08wCTDVz3K6DB TECDmx9IgwwuSURISTUwxpnO0l7ftlb93Nb6j+s0n0qX9mYZp+4K0PpkZNq95nqIz5mHU2ds 7JSUWPJWzeeSa+Oa+yejmhuiTiz4z3REXYx9ggKX06d3c5lMpz1v0VF6IaUlfq156Xc/beED LRL/GB21q71DPyi/3lq+Sj3rzGMHof9GEQ5r3/3mzxLsemk7o5Z/8Zs4JZbijERDLeai4kQA wB5g1vMCAAA= Archived-At: Subject: Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 18 May 2017 02:10:17 -0000 Hi Greg, Thanks for the review. Could you clarify which version you reviewed? (https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 or https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-00 ?) On Wed, May 17, 2017 at 11:54:03AM -0400, Greg Hudson wrote: > I have reviewed this draft and have no blocking objections. Some > non-blocking, editorial notes: > > Interoperability concerns are listed last for RC4, but second out of > three subsections for DES3. > > Section 5.2, "Modern encryption types such as [...] use" should have a > comma before "such as" and before "use". > > Section 5.2, "It is also best practice when [...], to" should have a > comma before "when". Also, "it is also best practice" doesn't seem > right. > > Section 5.3, "Because [...], this means that these application servers > also possess" should omit "this means that". I would also remove the > parenthetical for that sentence. > > Section 5.4, "cross-realm situations" should perhaps be "cross-realm > deployments". > > Section 6, in "ample justification for deprecating their use", "their" > appears to refer back to "The flaws", which doesn't seem quite right. > > Section 6, "blocksize" should be "block size". > > Section 6.1, "[nfold] is known not to provide effective mixing of the > input bits" is not backed up by a reference. (I don't know of a > reference.) The other items seem clearly editorial. For this one, do you think I should look harder for a reference, or drop down to "is believed not to provide"? Thanks again, Ben From nobody Wed May 17 19:37:35 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D290129B69; Wed, 17 May 2017 19:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o-rpVdJXmZo; Wed, 17 May 2017 19:37:31 -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 007FE129B3F; Wed, 17 May 2017 19:35:29 -0700 (PDT) X-AuditID: c618062d-527ff7000000248b-79-591d1bed7f52 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.86.09355.DEB1D195; Thu, 18 May 2017 05:58:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Wed, 17 May 2017 22:35:25 -0400 From: Daniel Migault To: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" CC: "curdle-chairs@ietf.org" , 'curdle' Thread-Topic: review of draft-ietf-curdle-des-des-des-die-die-die Thread-Index: AdLPf1TvBfzJEx88T9es3kEzPCJa1A== Date: Thu, 18 May 2017 02:35:24 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433@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_2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiO4HadlIgx/f9Sxm9mxgtti6cBaz xdOuI0wOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MroW7KeqWDbLsaKhYtWMjYw7ljK2MXIySEh YCJxpqeZvYuRi0NI4CijxOFtjUwQznJGiTMTXrGBVLEJGEm0HeoHquLgEBHIl2g86g4SZhYI ljg36wFYWFjARuJ+jy1EhaPEl7tRIBUiAnoSx85eYQWxWQRUJdbeP8cCYvMK+Eosm/oZLM4o ICbx/dQaJoiJ4hK3nsxngjhNQGLJnvPMELaoxMvH/1ghbCWJj7/ns0PU50s8757NDDFTUOLk zCcsExiFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcUFObrqR wSZGYDQck2DT3cF4f7rnIUYBDkYlHt5DorKRQqyJZcWVuYcYJTiYlUR4P3yUiRTiTUmsrEot yo8vKs1JLT7EKM3BoiTOO+H8hQghgfTEktTs1NSC1CKYLBMHp1QDY4TEyb+mE4Lu6P37x7BD emLO/syuH0FuXrqJntIKzx0svNdXf0iqS98ieO8ze/4Ehk/ruyZHHGcx+7wmnd9unr/tnu5W 6Q8Tuct0zjD6FHtFtc3+sOGxhIu69afDd5OmF75IC3kk/Vz5YkZPuKP5gQcbbTxOyqzOkltz VGbNe30pi+99s+3qlViKMxINtZiLihMBHgHqZoICAAA= Archived-At: Subject: [Curdle] review of draft-ietf-curdle-des-des-des-die-die-die 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, 18 May 2017 02:37:34 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft seems to me quite ready. Please find some small comments. 1. Updates / obsoletes should be mentioned in the header, abstract and i= ntro. 1. Status: wouldn't standard track be more appropriated ? Nits: Section 5.2 to the has function section 5.4: TGT needs to be defined. """ It is now believed that all machines that might be broken by disabling RC4 = are unsupported, and concerns about breaking them will be reduced. """ I see this sentence as reflecting a support team point of view. If an appli= cation runs on W2003 and save lifes, I prefer not breaking it. I believe the issue is that an important aspect of support is addressing vu= lnerabilities. As patches are not provided for these versions, these system= s becomes too vulnerable and authentication with Kerberos may provide limit= ed protection. In such situation, could Kerberos be disabled, and alternate= authentication may be used. Kerberos might be the preferred way to perform= authentication but what would be the other ways. The typical use case I se= e is a that new client will not be able to connect the service. I hardly se= e KDC, Services being updated while client are not updated. I am fine clear= ly saying that upgrading to newer version is recommended. OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. If th= e status is SHOULD NOT, it gives time for the transition. In that case comm= ent above may not require so detailed explanations. Then, do we have recomm= endation for the deprecation, such as specific message, logs...? Section 7. If SHOULD NOT is specified, maybe we should mention that the status is expe= cted to move to MUST NOT. Nits from the datatracker: idnits 2.14.01 /tmp/draft-ietf-curdle-des-des-des-die-die-die-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- -- The draft header indicates that this document obsoletes RFC4757, but t= he abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3961, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: -------------------------------------------------------------------------= --- (Using the creation date from RFC3961, updated by this document, for RFC5378 checks: 2004-02-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- The document date (May 1, 2017) is 16 days in the past. Is this intentional? Checking references for intended status: Informational -------------------------------------------------------------------------= --- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (=3D=3D), 4 comments = (--). Run idnits with the --verbose option for more detailed information abo= ut the items above. ---------------------------------------------------------------------------= ----- [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_2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft seems to me quite ready. Please find some = small comments.

 

  1. Updates / obsoletes should be mentioned in the header, abstract and i= ntro.

 

  1. Status: wouldn’t standard track be more appropriated ?

 

Nits:

 

Section 5.2

 
to the has function

 

section 5.4:

 

TGT needs to be defined.
 
 
“””
It is now believed that all machines that might be broken by disabling=
 RC4 are unsupported, and concerns about breaking them will be reduced. 
“””
 
I see this sentence as reflecting a support team point of view. If an =
application runs on W2003 and save lifes, I prefer not breaking it. 
 
I believe the issue is that an important aspect of support is addressi=
ng vulnerabilities. As patches are not provided for these versions, these s=
ystems becomes too vulnerable and authentication with Kerberos may provide =
limited protection. In such situation, could Kerberos be disabled, and alte=
rnate authentication may be used. Kerberos might be the preferred way to pe=
rform authentication but what would be the other ways. The typical use case=
 I see is a that new client will not be able to connect the service. I hard=
ly see KDC, Services being updated while client are not updated. I am fine =
clearly saying that upgrading to newer version is recommended.

 


OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. =
If the status is SHOULD NOT, it gives time for the transition. In that case=
 comment above may not require so detailed explanations. Then, do we have r=
ecommendation for the deprecation, such as specific message, logs…? <=
o:p>


 


Section 7. 


 


If SHOULD NOT is specified, maybe we should mention =
that the status is expected to move to MUST NOT.



 


Nits from the datatracker:


 


idnits 2.14.01



 


/tmp/draft-ietf-curdle-des-des-des-die-die-die=
-00.txt:


 


 
Checking boilerplate required by RFC 5378 and the IETF Trust (see


  http://trustee.ietf.org/license-info):


  ---------------------------------------------------=
-------------------------


 


     No issues found here.<=
/span>


 


  Checking nits according to http://www.ietf.org/id-i=
nfo/1id-guidelines.txt:


  ---------------------------------------------------=
-------------------------


 


     No issues found here.<=
/span>


 


  Checking nits according to http://www.ietf.org/id-i=
nfo/checklist :


  ---------------------------------------------------=
-------------------------


 


  -- The draft header indicates that this document ob=
soletes RFC4757, but the


     abstract doesn't seem to mention =
this, which it should.


 


  -- The draft header indicates that this document up=
dates RFC3961, but the


     abstract doesn't seem to mention =
this, which it should.


 


 


  Miscellaneous warnings:


  ---------------------------------------------------=
-------------------------


 


     (Using the creation date from RFC=
3961, updated by this document, for


     RFC5378 checks: 2004-02-11)<=
/o:p>


 


  -- The document seems to lack a disclaimer for pre-=
RFC5378 work, but may


     have content which was first subm=
itted before 10 November 2008.  If you


     have contacted all the original a=
uthors and they are all willing to grant


     the BCP78 rights to the IETF Trus=
t, then this is fine, and you can ignore


     this comment.  If not, you m=
ay need to add the pre-RFC5378 disclaimer.



     (See the Legal Provisions do=
cument at


     http://trustee.ietf.org/license-i=
nfo for more information.)


 


  -- The document date (May 1, 2017) is 16 days in th=
e past.  Is this


     intentional?

 


 


  Checking references for intended status: Informatio=
nal


  ---------------------------------------------------=
-------------------------


 


     No issues found here.<=
/span>


 


     Summary: 0 errors (**), 0 flaws (=
~~), 0 warnings (=3D=3D), 4 comments (--).


 


     Run idnits with the --verbose opt=
ion for more detailed information about


     the items above.


----------------------------------------------------------=
----------------------


 


 


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_2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433eusaamb107erics_-- From nobody Wed May 17 20:31: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 0719912EB13 for ; Wed, 17 May 2017 20:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO_fHHzJcKSp for ; Wed, 17 May 2017 20:31:39 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27673129B1A for ; Wed, 17 May 2017 20:26:38 -0700 (PDT) X-AuditID: 12074422-55bff70000006f66-47-591d146c15a4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 99.E2.28518.C641D195; Wed, 17 May 2017 23:26:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4I3QaZn019329; Wed, 17 May 2017 23:26:36 -0400 Received: from [18.101.8.134] (vpn-18-101-8-134.mit.edu [18.101.8.134]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4I3QYSk023757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 23:26:35 -0400 To: Benjamin Kaduk References: <20170518021005.GK39245@kduck.kaduk.org> Cc: curdle@ietf.org From: Greg Hudson Message-ID: <950c6ace-d34e-108c-a3db-d1bdb89a2af4@mit.edu> Date: Wed, 17 May 2017 23:26:33 -0400 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: <20170518021005.GK39245@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrpsrIhtp0HuPz2LrwlnMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuLnLpeAhc8WKL0tYGxgnMncxcnJICJhITLrbx9LFyMUhJLCY SeJy/xNWCGcjo8TNU7+ZIZyjTBJPV3SwgLQIC/hKbHt3mx3EFhFQklh8toUNxBYSiJGYc+IQ K4jNLCAs8e9zKxOIzSagLLF+/1awXl4BK4mGtWvAVrMIqEo8mfgRrEZUIELiYecudogaQYmT M5+A1XMKmErcbPzEBjFTT2LH9V9Q8+Ultr+dwzyBUWAWkpZZSMpmISlbwMi8ilE2JbdKNzcx M6c4NVm3ODkxLy+1SNdULzezRC81pXQTIzgoXZR2ME7853WIUYCDUYmHNyJAJlKINbGsuDL3 EKMkB5OSKK/rP6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4PH4FyvCmJlVWpRfkwKWkOFiVx XnGNxgghgfTEktTs1NSC1CKYrAwHh5IEr4iwbKSQYFFqempFWmZOCUKaiYMTZDgP0PBdQkA1 vMUFibnFmekQ+VOMuhxz7n19zyTEkpeflyolzisPUiQAUpRRmgc3B5xMUjnaXjGKA70lzPsb pIoHmIjgJr0CWsIEtKT5gTTIkpJEhJRUA6PWvwset+Zn3tnl/8bX/MiyyB0pEtbLHz7edGkB swOL++2jk34F3ODdYsLj2tO+sHHz8wPb7nW/PPXt6lGb2jOZWidvqr6QM8jgkTlocKPDZtaT K4K2M+YWfF2isuTxz1knLm59+Py3fbrZokgDf6GH94WWJfLfuPRNZarE4UPMl86G1emVzn/n qsRSnJFoqMVcVJwIAPWumVgBAwAA Archived-At: Subject: Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 18 May 2017 03:31:41 -0000 On 05/17/2017 10:10 PM, Benjamin Kaduk wrote: > Hi Greg, > > Thanks for the review. Could you clarify which version you > reviewed? > (https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 > or > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-00 > ?) I think the former. I took a look at draft-ietf-curdle-des-des-des-die-die-die-00 just now, and it looks the same to me. I do see a typo "implemneted" in section 6.2. From nobody Thu May 18 03:27:04 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 6D98512EAAF; Thu, 18 May 2017 03:27:03 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149510322340.6733.5861716189997589061@ietfa.amsl.com> Date: Thu, 18 May 2017 03:27:03 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-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: Thu, 18 May 2017 10:27:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Increase minimum recommended modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-01.txt Pages : 4 Date : 2017-05-18 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-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 Fri May 19 18:50: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 D04BE12894A for ; Fri, 19 May 2017 18:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RztwNsThJri7 for ; Fri, 19 May 2017 18:50:40 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912051204DA for ; Fri, 19 May 2017 18:50:39 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id m18so8813979lfj.0 for ; Fri, 19 May 2017 18:50:39 -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=43qIF/kaDBzD6AGlMwUXJRoOKtR7c/4OV8It4rABtn8=; b=UTu3FaAOtSMMtE24evF6b3FUHnDIY6I39xDyavpuIkjjoiFDBYnfNzM/eDPVHwLI0B ibWXuRMeKDfEcHjIEi2MP/elpfNOtLDSZmMU8XtrmnRmcCrljwIerj70eDzknKa06tsk pTh4/CWTs8289jUdZFb4s7ZX4musEIWzEyfeKLnWNrDVLrLqumPaLO1oM29AqJhcCu7P pJbiC1lY1d7cbe6bmJTbK6jGm+E3vFXsXu9zPBlZZrz0x28DOXpyC/wkuHHFNTBzLQkJ HKa85x+oOpyaWciLEtMDAo8KW+r2xTt78C2V/iGs2G4rzqL+mJtY8K9yunLCLJUDiSl8 QqQw== 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=43qIF/kaDBzD6AGlMwUXJRoOKtR7c/4OV8It4rABtn8=; b=mC8qXgaDZRC6oDy5EUY2SfAPD/xCpNXjsbgJza0XUJNBR2hZzNHQeoxn0xD6/1wAKf uVj5gYmf1q59uU0I5TEjhGmaU5fSkTcVOvAZx4OM1+uR6Z10+LmPJCd5niscCGC6bj6m OFCoItiDsnMVvY6iSqqGa8LhxifhtRAqO0wDdJdPcO6eI6mkp/xh0BALWMsCo0NtQn6c NJ+4QwxMWaw+eFFmNMxrAEzUKXIQjvAJa/8aYubmpIOwz/BLsMsAmRgA9WFAUqxkZ3td UKvFYgwKQi/vPn2o1+712kImbPrd2Xo2uk83zDkpIptKl3EoE1Ee+FS0Gw6rCKds+1O5 /ttg== X-Gm-Message-State: AODbwcBPd9xHOzGGREeVzH4rMGuKI8RoA1Nmk7eqmbhVoNz6V3jF4fGP CVq25BYWRAjC6oUj9hjDUroKlUno9w== X-Received: by 10.25.115.71 with SMTP id o68mr2712182lfc.96.1495245037890; Fri, 19 May 2017 18:50:37 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.84.13 with HTTP; Fri, 19 May 2017 18:50:36 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <590A2FA0.3070601@roumenpetrov.info> <590ABDAD.6000900@roumenpetrov.info> <590B7E60.8000204@roumenpetrov.info> From: Daniel Migault Date: Fri, 19 May 2017 21:50:36 -0400 X-Google-Sender-Auth: Z_aAG5YdekuZc4X98FEDjqIT6dg Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="001a113c477455eed7054feadd00" Archived-At: Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm 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, 20 May 2017 01:50:43 -0000 --001a113c477455eed7054feadd00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Denis for the clarification on the mailing list. It seems the proposed version reached consensus as none opposed for the last 12 days. If you think otherwise, please mention it as soon as possible. I am planning to move the draft forward next week for AD review.. Yours, Daniel On Sun, May 7, 2017 at 9:01 PM, denis bider wrote: > Roumen and I have exchanged details over the weekend. My understanding no= w > is as follows. > > *Server-side situation:* > > OpenSSH versions before 7.5 (such as 7.3) send the "server-sig-algs" > extension, but they only use it to indicate support for "rsa-sha2-512" an= d > "rsa-sha2-256". They do not include other public key algorithms that the > server supports, even though the server will accept those algorithms if > they are attempted. > > It is intended that the server should send a complete set of accepted > public key algorithms. My understanding is that OpenSSH versions 7.5 and > later do this. Bitvise SSH Server has always sent a complete list. > > *Client-side situation:* > > There exist clients which have problems with OpenSSH 7.3 behavior, and > clients that don't. > > *Clients with explicit public key configuration.* Bitvise SSH Client does > not have a problem with this behavior, because it does not use public key= s > opportunistically. Our SSH Client will use a public key to authenticate > only if the key is explicitly configured by the user. It will use only th= e > requested key, and not other keys that it may find in various places of > storage. > > As a result, our SSH Client has no use for a hint from the server about > which key types are OK to use. It already knows the key it's going to use= . > The question is what signature algorithm (now renamed "public key > algorithm") to use with that key. For this purpose, the information sent = by > OpenSSH is sufficient, regardless of version. For RSA keys, the > "server-sig-algs" extension provides the info. For non-RSA keys, there's > only one algorithm possible anyway, so we use it. > > *Clients with opportunistic key search.* Other SSH clients, including > OpenSSH and PKIXSSH (Roumen's work) do not require a public key to be > explicitly configured in order to be used. Such clients perform an > opportunistic search, and try to use any and all keys that might work tha= t > can be found in various places of storage. This includes the user's .ssh > directory, keys available via the SSH agent protocol, and keys specified = on > the command line. > > These types of clients have a problem, because: > > - In OpenSSH versions 7.5 and higher, the client can use the list of > algorithms sent in the server's "server-sig-algs" extension to narrow dow= n > the public keys it's going to try. If the server doesn't list ECDSA or DS= A, > for example, the client can take that as authoritative, and can exclude > those keys from authentication. This is nice because it may involve tryin= g > fewer keys. > > - In OpenSSH version 7.3, the server will only send "rsa-sha2-256" and > "rsa-sha2-512", even if the server also accepts ECDSA and other algorithm= s. > This means the client needs to have explicit treatment to detect the > OpenSSH protocol version. If the OpenSSH version is older than 7.5, > "server-sig-algs" can still be used to enable the use of "rsa-sha2-XXXX" > instead of "ssh-rsa", but it cannot be used to exclude non-RSA keys in > authentication. > > *Options:* > > *(A) Rename extension.* Roumen has requested that we rename the > "server-sig-algs" extension and make it clear that the server must send a= ll > algorithms it will accept. > > I think this is not the best thing to do for the following reasons: > > - There are multiple implementations of this extension which are not > impacted by the OpenSSH 7.3 issue. These implementations would suffer fro= m > the rename. > > - Implementations that are impacted by the OpenSSH 7.3 issue may still > have a requirement to interoperate with OpenSSH 7.5, as well as other > servers that currently send "server-sig-algs" with a complete list of > algorithms. For such implementations, renaming the extension is again not= a > fix, but a further complication. > > *(B) Workaround by clients that need it.* My suggestion is that clients > that use opportunistic key search, and wish to interoperate with OpenSSH > 7.3, should implement a compatibility workaround for the way > "server-sig-algs" is sent by that version. > > I think this is the better solution for the following reasons: > > - There are multiple implementations which are already not affected by th= e > issue, whether communicating with OpenSSH or between themselves. In this > case, those implementations do not need to change anything. > > - The work required for clients with opportunistic key search is similar > to the work required in above option A), *assuming *those clients want to > interoperate with OpenSSH 7.5+ and other existing servers that send > "server-sig-algs" with a complete list of algorithms. > > In addition, it appears the draft needs to be clarified to state: > > - The server SHOULD send a complete list of public key algorithms it will > accept for user authentication. > > - The client MAY authenticate with a public key algorithm not included in > the server's list. > > At this time, I will make this update to the draft. > > denis > > > > On Fri, May 5, 2017 at 4:15 AM, denis bider > wrote: > >> Talking to Roumen off-list to gain a better understanding of his >> implementation, and why it has trouble dealing with "server-sig-algs" se= nt >> by OpenSSH versions before 7.5. Our implementation does not have trouble= . >> His implementation might though, perhaps due to different combinations o= f >> supported algorithms, and/or a different design approach. Trying to >> understand this better. Will post when I do. >> >> On Fri, May 5, 2017 at 12:18 AM, denis bider >> wrote: >> >>> Although my below response was self-explanatory, it is not sufficient. >>> It requires elaboration: >>> >>> - The extension being specified is already deployed in a variety of >>> implementations, not only OpenSSH. (See [1] at bottom) >>> >>> - Since the draft thus far remains compatible with existing >>> implementations, changing the name of the extension would break >>> compatibility. >>> >>> - Breaking compatibility with existing implementations requires a >>> substantive reason. I am currently not aware of a substantive reason to= do >>> this. >>> >>> - A problem in particular versions of a particular implementation is no= t >>> a substantive reason. Idiosyncrasies of specific implementations are >>> handled by others recognizing the SSH version string, not diverging the >>> protocol. >>> >>> - It is not clear to me that the problem you reference in OpenSSH >>> versions prior to 7.5 is a problem that needs to be addressed at this l= evel. >>> >>> - In a previous message, Damien Miller, who is representative of OpenSS= H >>> in this forum, has expressed a preference to keep the same extension na= me. >>> >>> To be clear, the extension name is not one I'm overly happy with. In >>> fact, I had changed the name of the extension from "server-sig-algs" to >>> something more appropriate in an early version of the draft. However, b= y >>> that time, another implementation already picked up "server-sig-algs". >>> >>> For this reason, I changed the spec back to "server-sig-algs". Although >>> the name is not ideal, it is now in use; and the name being ideal is >>> strictly less important than there being one identifier; and one identi= fier >>> only; for the same concept, if reasonably possible. >>> >>> I stand by this decision, and think it's incorrect to modify the name a= t >>> this time, unless the mechanics of the extension are changed in some wa= y >>> that's fundamental. >>> >>> [1] According to this excellent, but at this time slightly outdated >>> comparison: >>> >>> http://ssh-comparison.quendi.de/comparison/hostkey.html >>> >>> ... implementations of rsa-sha2-*** public key algorithms include >>> AsyncSSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also sup= port >>> them, but this is not listed in the chart. This leads me to believe the= re >>> may be other implementations also. I know that at least three of these >>> implementations also implement the "server-sig-algs" extension under it= s >>> current name. >>> >>> >>> On Thu, May 4, 2017 at 11:12 PM, denis bider >>> wrote: >>> >>>> > 10x for new versions. >>>> >>>> You don't even have the decency to spell that. >>>> >>>> >>>> > The name of extension "server-sig-algs" must be changed as well. >>>> >>>> No fucking way. Fuck off. >>>> >>>> >>>> >>>> On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F= =D0=B5=D1=82=D1=80=D0=BE=D0=B2 >>> > wrote: >>>> >>>>> Hi denis, >>>>> >>>>> denis bider wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> in the interest of consensus, I have adopted the requested terminolo= gy >>>>>> changes in the two drafts. What was previously "signature algorithm" >>>>>> is now >>>>>> "public key algorithm", and what was previously "public key >>>>>> algorithm" is >>>>>> now "public key format". >>>>>> >>>>>> Please review and let me know. >>>>>> >>>>> 10x for new versions. >>>>> >>>>> Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. >>>>> I still think that chapter 4 IANA Considerations could be simplified >>>>> to list only public key algorithm but this is not so important. >>>>> The chapter refer to RFC4250 but section 7.1 Normative References lac= k >>>>> reference to it. May be is good to list RFC4250 as well. >>>>> No other remarks. >>>>> >>>>> >>>>> >>>>> About draft-ietf-curdle-ssh-ext-info-06.txt: >>>>> The name of extension "server-sig-algs" must be changed as well. >>>>> First because extension contain abbreviation of signature in name >>>>> (description is fine), >>>>> second because existing implementation does not follow rules from >>>>> RFC4250, section 4.6.1. "Conventions for Names" and >>>>> third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA >>>>> signature methods were not being correctly advertised..." fixed in 7.= 5. >>>>> >>>>> >>>>> [SNIP] >>>>> >>>>> Regards, >>>>> Roumen Petrov >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > --001a113c477455eed7054feadd00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Denis for the clarification on the mailin= g list. It seems the proposed version reached consensus as none opposed for= the last 12 days. If you think otherwise, please mention it as soon as pos= sible. I am planning to move the draft forward next week for AD review..
Yours,
Daniel

=
On Sun, May 7, 2017 at 9:01 PM, denis bider <denisbider.ietf@gmail.com> wrote:
Roumen and I have exchanged details ove= r the weekend. My understanding now is as follows.

Server-side situation:

OpenSSH versions be= fore 7.5 (such as 7.3) send the "server-sig-algs" extension, but = they only use it to indicate support for "rsa-sha2-512" and "= ;rsa-sha2-256". They do not include other public key algorithms that t= he server supports, even though the server will accept those algorithms if = they are attempted.

It is intended that the server= should send a complete set of accepted public key algorithms. My understan= ding is that OpenSSH versions 7.5 and later do this. Bitvise SSH Server has= always sent a complete list.

Client-side situa= tion:

There exist clients which have problems = with OpenSSH 7.3 behavior, and clients that don't.

=
Clients with explicit public key configuration. Bitvise SSH Cli= ent does not have a problem with this behavior, because it does not use pub= lic keys opportunistically. Our SSH Client will use a public key to authent= icate only if the key is explicitly configured by the user. It will use onl= y the requested key, and not other keys that it may find in various places = of storage.

As a result, our SSH Client has no use= for a hint from the server about which key types are OK to use. It already= knows the key it's going to use. The question is what signature algori= thm (now renamed "public key algorithm") to use with that key. Fo= r this purpose, the information sent by OpenSSH is sufficient, regardless o= f version. For RSA keys, the "server-sig-algs" extension provides= the info. For non-RSA keys, there's only one algorithm possible anyway= , so we use it.

Clients with opportunistic key = search.=C2=A0Other SSH clients, including OpenSSH and PKIXSSH (Roumen&#= 39;s work) do not require a public key to be explicitly configured in order= to be used. Such clients perform an opportunistic search, and try to use a= ny and all keys that might work that can be found in various places of stor= age. This includes the user's .ssh directory, keys available via the SS= H agent protocol, and keys specified on the command line.

These types of clients have a problem, because:

- In OpenSSH versions 7.5 and higher, the client can use the list of = algorithms sent in the server's "server-sig-algs" extension t= o narrow down the public keys it's going to try. If the server doesn= 9;t list ECDSA or DSA, for example, the client can take that as authoritati= ve, and can exclude those keys from authentication. This is nice because it= may involve trying fewer keys.

- In OpenSSH versi= on 7.3, the server will only send "rsa-sha2-256" and "rsa-sh= a2-512", even if the server also accepts ECDSA and other algorithms. T= his means the client needs to have explicit treatment to detect the OpenSSH= protocol version. If the OpenSSH version is older than 7.5, "server-s= ig-algs" can still be used to enable the use of "rsa-sha2-XXXX&qu= ot; instead of "ssh-rsa", but it cannot be used to exclude non-RS= A keys in authentication.

Options:

(A) Rename extension. Roumen has requested that we = rename the "server-sig-algs" extension and make it clear that the= server must send all algorithms it will accept.

I= think this is not the best thing to do for the following reasons:

- There are multiple implementations of this extension whi= ch are not impacted by the OpenSSH 7.3 issue. These implementations would s= uffer from the rename.

- Implementations that are = impacted by the OpenSSH 7.3 issue may still have a requirement to interoper= ate with OpenSSH 7.5, as well as other servers that currently send "se= rver-sig-algs" with a complete list of algorithms. For such implementa= tions, renaming the extension is again not a fix, but a further complicatio= n.

(B) Workaround by clients that need it.= =C2=A0My suggestion is that clients that use opportunistic key search, and = wish to interoperate with OpenSSH 7.3, should implement a compatibility wor= karound for the way "server-sig-algs" is sent by that version.

I think this is the better solution for the followin= g reasons:

- There are multiple implementations wh= ich are already not affected by the issue, whether communicating with OpenS= SH or between themselves. In this case, those implementations do not need t= o change anything.

- The work required for clients= with opportunistic key search is similar to the work required in above opt= ion A), assuming=C2=A0those clients want to interoperate with OpenSS= H 7.5+ and other existing servers that send "server-sig-algs" wit= h a complete list of algorithms.

In addition, it a= ppears the draft needs to be clarified to state:

-= The server SHOULD send a complete list of public key algorithms it will ac= cept for user authentication.

- The client MAY aut= henticate with a public key algorithm not included in the server's list= .

At this time, I will make this update to the dra= ft.

denis



On Fri, May 5, 2017 at 4= :15 AM, denis bider <denisbider.ietf@gmail.com> wrot= e:
Talking to Roumen off= -list to gain a better understanding of his implementation, and why it has = trouble dealing with "server-sig-algs" sent by OpenSSH versions b= efore 7.5. Our implementation does not have trouble. His implementation mig= ht though, perhaps due to different combinations of supported algorithms, a= nd/or a different design approach. Trying to understand this better. Will p= ost when I do.=C2=A0

On Fri, May 5, 2017 at 12:18 AM, denis bider <denisb= ider.ietf@gmail.com> wrote:
Although my below response was self-explanatory, it is no= t sufficient. It requires elaboration:

- The extension b= eing specified is already deployed in a variety of implementations, not onl= y OpenSSH. (See [1] at bottom)

- Since the draft t= hus far remains compatible with existing implementations, changing the name= of the extension would break compatibility.

- Bre= aking compatibility with existing implementations requires a substantive re= ason. I am currently not aware of a substantive reason to do this.

- A problem in particular versions of a particular impleme= ntation is not a substantive reason. Idiosyncrasies of specific implementat= ions are handled by others recognizing the SSH version string, not divergin= g the protocol.

- It is not clear to me that the p= roblem you reference in OpenSSH versions prior to 7.5 is a problem that nee= ds to be addressed at this level.

- In a previous = message, Damien Miller, who is representative of OpenSSH in this forum, has= expressed a preference to keep the same extension name.

To be clear, the extension name is not one I'm overly happy with= . In fact, I had changed the name of the extension from "server-sig-al= gs" to something more appropriate in an early version of the draft. Ho= wever, by that time, another implementation already picked up "server-= sig-algs".

For this reason, I changed the spe= c back to "server-sig-algs". Although the name is not ideal, it i= s now in use; and the name being ideal is strictly less important than ther= e being one identifier; and one identifier only; for the same concept, if r= easonably possible.

I stand by this decision, and = think it's incorrect to modify the name at this time, unless the mechan= ics of the extension are changed in some way that's fundamental.
<= div>
[1] According to this excellent, but at this time slight= ly outdated comparison:


<= div>... implementations of rsa-sha2-*** public key algorithms include Async= SSH, SmartFTP, and OpenSSH. Bitvise SSH Server and Client also support them= , but this is not listed in the chart. This leads me to believe there may b= e other implementations also. I know that at least three of these implement= ations also implement the "server-sig-algs" extension under its c= urrent name.


On T= hu, May 4, 2017 at 11:12 PM, denis bider <denisbider.ietf@gmail.co= m> wrote:
= >=C2=A010x for new versions.
You don't even have the decency to spell that.


>=C2=A0The name of extensi= on "server-sig-algs" must be changed as well.

No fucking way. Fuck off.

On Thu, May 4, 2017 at 1:17 PM, =D0=A0=D1=83= =D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 &= lt;pkixssh@r= oumenpetrov.info> wrote:
Hi= denis,

denis bider wrote:
Hello everyone,

in the interest of consensus, I have adopted the requested terminology
changes in the two drafts. What was previously "signature algorithm&qu= ot; is now
"public key algorithm", and what was previously "public key = algorithm" is
now "public key format".

Please review and let me know.
 10x for new versions.

Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me. I still think that chapter 4 IANA Considerations could be simplified to lis= t only public key algorithm but this is not so important.
The chapter refer to RFC4250 but section 7.1 Normative References lack refe= rence to it. May be is good to list RFC4250 as well.
No other remarks.



About draft-ietf-curdle-ssh-ext-info-06.txt:
The name of extension "server-sig-algs" must be changed as well.<= br> First because extension contain=C2=A0 abbreviation of signature in name (de= scription is fine),
second because existing implementation does not follow rules from RFC4250, = section 4.6.1. "Conventions for Names" and
third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA sig= nature methods were not being correctly advertised..." fixed in 7.5.

[SNIP]

Regards,
Roumen Petrov
=

_______________________________________________
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

--001a113c477455eed7054feadd00-- From nobody Fri May 19 19:15: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 824451293E0 for ; Fri, 19 May 2017 19:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI9GMyxRnzZ7 for ; Fri, 19 May 2017 19:15:25 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B3012778D for ; Fri, 19 May 2017 19:15:25 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id m18so8926668lfj.0 for ; Fri, 19 May 2017 19:15:25 -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=fi0h4dKsILG9cGJAGX865F3oM4dXdNH6/6c6FkrK53U=; b=p0DzjVIsqJNCwHbtuoVLjJ75Tdg0jS5K0jQDzHx1sO/ImYyaUAWf/4t8R8uxbKQyr2 c8+ZEzpC60BbDcShGUMOjoSVeoeoKKAA1IOSt1kZcM7J4dkyscQX1KMtaE1VUClTjP8y HFkd4klZF3kxX9LShhTFDU3GX80UaYOTTTPjDSPBi2bqOtuxSqtIchYretXZ8xu40TNy m0rsh6u1AEVxVBwOeLXRvBxmYjEBTgbqKDucnP+quwDLH5XDZRLYNiuA2kVsRc6fL9Qr BLNo+DHBFDZmbw9eHz9xd6Vad3ZDRJXg5CsGEjj3lRrsxWZpM/0tGgKt0ZQMNngwQqHN Geig== 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=fi0h4dKsILG9cGJAGX865F3oM4dXdNH6/6c6FkrK53U=; b=Km4dkpQxVQ5zUjoirfhopg+XL02xwk+Dq/hdq93c+/b40vnWWaBO+7Fx5y5xg6qx2A ga6Df2xirXD65OTpKdGDZqwapQuwBzDZqrdbWQm09kYI8suyuJhCraf4UvgvUFP3FvTZ ghhvvsStf7ry+3e4ImL03kEWHqZCvsBvlDe6hQtZuQc1NGqO/EQBRW+ptF8QiS/Q7qlZ d5Jzl89pWW/tGmQz7KnX4TROigGptF2Lutwm+zTu8wz8ewC6oxvUUM9WVZmyKXnfVb1H oXzqwjtxIlzvaPEUAo58yKfGpC1Yj9O4EZ3hvTEtuXgFeIu3x00uQ2IaHeiZPMDqlALC HQtQ== X-Gm-Message-State: AODbwcCKKmhZRC5jwA8udVxVBxjhGQMRQbHPxn18Ku8Q+Uqh44McijP8 ShmPEH3H7w/jPviJ0N1EB+WXBla6WKtb X-Received: by 10.25.208.14 with SMTP id h14mr1953083lfg.174.1495246523614; Fri, 19 May 2017 19:15:23 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 19:15:23 -0700 (PDT) From: Daniel Migault Date: Fri, 19 May 2017 22:15:23 -0400 X-Google-Sender-Auth: x5di057NtTl_pc0wk4oSOrk0p9k Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a11412d3ce44d0d054feb3574" Archived-At: Subject: [Curdle] CURDLE status 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, 20 May 2017 02:15:27 -0000 --001a11412d3ce44d0d054feb3574 Content-Type: text/plain; charset="UTF-8" Hi, The following drafts are in WGLC and seems to have reached consensus. If you think otherwise, please provide your feed backs as soon as possible. These draft are expected to be moved forward to the IESG next week. - https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ - https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ - https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ - https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ The following drafts under reviews. Feel free to provide comments and update these drafts so they can be ready for WGLC by the end of the month. - https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ - https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ - https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ Yours, Daniel --001a11412d3ce44d0d054feb3574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The following drafts = are in WGLC and seems to have reached consensus. If you think otherwise, pl= ease provide your feed backs as soon as possible. These draft are expected = to be moved forward to the IESG next week.

=C2=A0=C2=A0=C2=A0 - h= ttps://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/
=C2= =A0=C2=A0=C2=A0 - https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2= /
=C2=A0=C2=A0=C2=A0 - https://datatracker.ietf.org/doc= /draft-ietf-curdle-des-des-des-die-die-die/
=C2=A0=C2=A0=C2=A0 - https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/=

The following drafts under reviews. Feel free to provide comments a= nd update these drafts so they can be ready for WGLC by the end of the mont= h.
=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 - https://datatracker.= ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/
=C2=A0=C2=A0=C2=A0 - = https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-= exchange/
=C2=A0=C2=A0=C2=A0 - https://datatracker.ietf.org/doc/= draft-schaad-curdle-oid-registry/

Yours,
Daniel= =C2=A0



--001a11412d3ce44d0d054feb3574-- From nobody Sun May 21 13:14: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 743F912944A for ; Sun, 21 May 2017 13:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djhXupHL_ohy for ; Sun, 21 May 2017 13:13:57 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9168A129443 for ; Sun, 21 May 2017 13:13:57 -0700 (PDT) X-AuditID: 12074422-4dfff7000000196e-43-5921f5036adc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EA.D3.06510.305F1295; Sun, 21 May 2017 16:13:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4LKDsBS011337; Sun, 21 May 2017 16:13:54 -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 v4LKDo8a021768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 May 2017 16:13:53 -0400 Date: Sun, 21 May 2017 15:13:50 -0500 From: Benjamin Kaduk To: Hubert Kario Cc: curdle@ietf.org Message-ID: <20170521201350.GP39245@kduck.kaduk.org> References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT12X5qhhp0LGIx2LrwlnMFre+HWZ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDK+bf3GXDBTuOLS7WlsDYyH+bsYOTkkBEwk vt3+xdrFyMUhJLCYSWLl1tfsEM5GRomFs2+yQThXmSR+zFrKBNLCIqAqsWrvG3YQm01ARaKh +zIziC0CZJ891QlmMwsIS/z73ApUz8EhLJAnsfBGOEiYF2jbv1+vWUBsIYEyiXlT3zNCxAUl Ts58wgLRqiVx499LsFZmAWmJ5f84IMLaEssWvmYGCXMK2EpsvpcIEhYVUJb4e/geywRGwVlI Bs1CMmgWwqBZSAYtYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERzSLko7 GCf+8zrEKMDBqMTD+2KuQqQQa2JZcWXuIUZJDiYlUd5XM4FCfEn5KZUZicUZ8UWlOanFhxgl OJiVRHi3XFWMFOJNSaysSi3Kh0lJc7AoifOKazRGCAmkJ5akZqemFqQWwWRlODiUJHg7PgM1 ChalpqdWpGXmlCCkmTg4QYbzAA1vAKnhLS5IzC3OTIfIn2JUlBLnPQiSEABJZJTmwfWCUo5E 9v6aV4ziQK8I87p+AariAaYruO5XQIOZgAZbP5MHGVySiJCSamBkfrJzyoTt1x8L2riyTV7a E8e8jmW1p8c7dss5nHvDPRJC+PpPfn+yqmeqYIeAdmDOAZ73sgriHy7/im6226vy5cJ7C4fJ 9kLe9xZcLtx07JEXv/2LqHKXHV+mObUU55x4H83/vP2C3CH267zfJnT9X8NSnC20p0tszVZp W/V2vb+X9gh8s+1QYinOSDTUYi4qTgQATkWGnhQDAAA= Archived-At: Subject: Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 20:13:59 -0000 On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote: > On Saturday, 29 April 2017 15:28:43 CEST internet-drafts@ietf.org wrote: >=20 > One of the nice properties of Kerberos, because it uses only symmetric=20 > cryptography, is that it is secure against quantum computer attacks. [obligatory note that the GSS-API is generic, i.e., there are non-Kerberos GSS mechanisms, some of which are even used with ssh today. AIUI, the GSI mech does not use symmetric crypto and could not reasonably become quantum-computer-resistant.] > Unfortunately, neither the previous gss-api kex scheme, nor the one we=20 > proposed here (as it is essentially the same), maintain that property. > This is because the input to the HASH function, with one exception, are= =20 > transferred in clear. That only secret input is the value calculated usin= g=20 > algorithm vulnerable to quantum computers - FF or EC version of Diffie-He= llman >=20 > Thus my question are,=20 > 1). should we change the input provided to HASH to provide quantum comput= er=20 > resistance, or We should probably provide a scheme that has some additional input(s) to HASH, perhaps with a GSS_Pseudo_random() (RFC 4401) or a GSS_Wrap()'d random value. > 2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes (a= nd=20 > forget about QC-resistance - that's the current draft), or But, I'm not convinced that we want to make "gss--" have different global semantics based on the particular group+hash combination;=20 > 3). should we multiply the kex options further and provide QC-resistant= =20 > variants of all the GSSAPI kex algorithms? it seems like it would make more sense to have a separate document that creates a new family of gss-pq-- keyex schemes, though probably only of the new ones from this document and not the SHA1 ones. >=20 > As for technical details, I was thinking of adding a step in which the pe= ers=20 > each choose a random value, GSS_Wrap it, send it to peer, GSS_Unwrap peer= s=20 > value and append their value and the peers decrypted value to HASH input. That probably suffices; I would have to think a bit harder about where there is any value gained from using such wrapped random values as input to GSS_Pseudo_random(), or whether just passing the HASH inputs as the prf_in input would suffice (which would mean less data going on the wire). -Ben From nobody Sun May 21 13:17: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 43C721252BA; Sat, 20 May 2017 18:57:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: curdle@ietf.org, curdle-chairs@ietf.org, ekr@rtfm.com, mglt.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149533182118.23517.11625169747049857085.idtracker@ietfa.amsl.com> Date: Sat, 20 May 2017 18:57:01 -0700 Archived-At: X-Mailman-Approved-At: Sun, 21 May 2017 13:17:55 -0700 Subject: [Curdle] curdle - New Meeting Session Request for IETF 99 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 01:57:01 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the curdle working group. --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 15 Conflicts to Avoid: First Priority: acme anima cfrg dnsop dots homenet ipsecme irtfopen lamps lpwan lwig nfvrg quic saag sacm secevent nvo3 tls People who must be present: Eric Rescorla Rich Salz Daniel Migault Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun May 21 13:26: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 D8BD61293E3 for ; Sun, 21 May 2017 13:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-MSu5WJHgPN for ; Sun, 21 May 2017 13:25:58 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877571292AE for ; Sun, 21 May 2017 13:25:58 -0700 (PDT) X-AuditID: 1209190c-b85ff70000007961-3d-5921f7d549cb Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.9D.31073.5D7F1295; Sun, 21 May 2017 16:25:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v4LKPuWN030306 for ; Sun, 21 May 2017 16:25:56 -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 v4LKPrbt024409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 21 May 2017 16:25:56 -0400 Date: Sun, 21 May 2017 15:25:53 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170521202553.GQ39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUixG6nonv1u2KkQcdNeYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoErY//kH+wF6wQqFh37yNbA2M/bxcjJISFgInHww262LkYuDiGB xUwSV58fYgRJCAkcZ5S4/t8Zwn7NJPG+xRHEZhFQlZj0dAsziM0moCLR0H0ZyObgEBEQluhZ IAkSFhYwk9h44TRYCS/Q/H8zrrBB2IISJ2c+YQGxmQW0JG78e8kE0sosIC2x/B8HSFhUQFni 7+F7LBMYeWch6ZiFpGMWQscCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsY QUHEKcmzg/HMG69DjAIcjEo8vA4LFCKFWBPLiitzDzFKcjApifK+mgkU4kvKT6nMSCzOiC8q zUktPsQowcGsJMK75apipBBvSmJlVWpRPkxKmoNFSZxXQqMxQkggPbEkNTs1tSC1CCYrw8Gh JMF7/RtQo2BRanpqRVpmTglCmomDE2Q4D9Bw9u8gw4sLEnOLM9Mh8qcYFaXEeX1BmgVAEhml eXC9oCiXyN5f84pRHOgVYd4UkCoeYIKA634FNJgJaLD1M3mQwSWJCCmpBsbkJ4rvVGK9IlTm aD+8dLjrR/B3eZmNCdsq73bmfc370rg7Of5xEstFE067KW+0ovZMK/aJEpdOMZ3xbxubmV5b xa2JPA8km7ner02XdD3Q++XLRvatgh2zW2WX/Ha26X4lNX1W69+3OvPKphX3c1Sc/Z9/vP/J 7prUM4JPczjc9XmmV/6Sd1BiKc5INNRiLipOBABJFip7zQIAAA== Archived-At: Subject: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 20:26:00 -0000 Generally, this document is in good shape, and I think we should move it forward. My main comment/objection is that the security considerations should note that the combination of GSS key exchange, GSS delegated credentials, and use of insecure DNS to modify the requested server principal name result in a situation where an attacker can easily obtain a valid TGT+key for the client principal. Obviously, RFCs 4462, 4120, etc. all implore us to not use insecure DNS in such a fashion, but nonetheless major Kerberos libraries continue to do so. At MIT we have disabled GSS key exchange for ssh because we default to GSS credential delegation. Some other nit-level comments: On page 8, in step 5 of the procedure, do we want to give a reference or two for the shared-secret computation above the existing prose? (Also, is the d_U and q_V terminology standard from some related document? I did not see them in RFC 4462.) Also on page 8, step 6 could further clarify that this only occurs when the server's final call to GSS_Accept_sec_context() returns GSS_S_COMPLETE; anything else is an error condition. Relatedly, the way the GSS context negotiation loop's exit conditions are split between step 6 and step 2 confused me a little on first read, but it seems correct, and along with the RFC 7546 reference I think readers will be okay. On page 11, the description of the HASH input has a couple of inconsistencies -- in RFC 4462, V_S is the server's "version" string, though here we have it as the server's "identification" string. I don't think that's a problem per se, but wanted to note it just in case. Also, V_S excludes CR and LF, but V_C excludes CR and NL; we should probably be consistent about NL vs. LF. In sections 5.2.2 and later we continue to include refeferences for MD5, DER, and Base64; RFC 4462 only included those references in the first corresponding subsection. At this point, it's probably not worth making any changes, though. And one editorial note: On page 6, "non- zero" should not have a space. -Ben From nobody Mon May 22 06:28: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 0704A12EA42 for ; Mon, 22 May 2017 06:28:02 -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 0mkpqOllnLgr for ; Mon, 22 May 2017 06:28:00 -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 4941F12EA53 for ; Mon, 22 May 2017 06:27:54 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 94E6090905; Mon, 22 May 2017 13:27:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 94E6090905 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=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 94E6090905 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3AA9280E92; Mon, 22 May 2017 13:27:54 +0000 (UTC) From: Hubert Kario To: Benjamin Kaduk Cc: curdle@ietf.org Date: Mon, 22 May 2017 15:27:47 +0200 Message-ID: <1674834.KTPl0iozjd@pintsize.usersys.redhat.com> In-Reply-To: <20170521201350.GP39245@kduck.kaduk.org> References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com> <20170521201350.GP39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3294733.JPtQj2RNT1"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 22 May 2017 13:27:54 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:28:02 -0000 --nextPart3294733.JPtQj2RNT1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Sunday, 21 May 2017 22:13:50 CEST Benjamin Kaduk wrote: > On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote: > > On Saturday, 29 April 2017 15:28:43 CEST internet-drafts@ietf.org wrote: > >=20 > > One of the nice properties of Kerberos, because it uses only symmetric > > cryptography, is that it is secure against quantum computer attacks. >=20 > [obligatory note that the GSS-API is generic, i.e., there are > non-Kerberos GSS mechanisms, some of which are even used with ssh > today. AIUI, the GSI mech does not use symmetric crypto and could > not reasonably become quantum-computer-resistant.] Yes, the change is necessary, but not sufficient, for QC resistance. > > Unfortunately, neither the previous gss-api kex scheme, nor the one we > > proposed here (as it is essentially the same), maintain that property. > > This is because the input to the HASH function, with one exception, are > > transferred in clear. That only secret input is the value calculated us= ing > > algorithm vulnerable to quantum computers - FF or EC version of > > Diffie-Hellman > >=20 > > Thus my question are, > > 1). should we change the input provided to HASH to provide quantum > > computer > > resistance, or >=20 > We should probably provide a scheme that has some additional input(s) to > HASH, perhaps with a GSS_Pseudo_random() (RFC 4401) or a > GSS_Wrap()'d random value. GSS_Pseudo_random() could be a neat solution. But I have some reservations,= =20 see below. > > 2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes > > (and > > forget about QC-resistance - that's the current draft), or >=20 > But, I'm not convinced that we want to make "gss--" > have different global semantics based on the particular group+hash > combination; What I was thinking, is that -sha1 ones are becoming insecure either way. S= o=20 lets make sure that the only ones that remain have the same properties (and= =20 they are a superset of the -sha1 ones). =20 > > 3). should we multiply the kex options further and provide QC-resistant > > variants of all the GSSAPI kex algorithms? >=20 > it seems like it would make more sense to have a separate document > that creates a new family of gss-pq-- keyex schemes, > though probably only of the new ones from this document and not the > SHA1 ones. yes, using sha-1 for PQ is quite silly. For gss-pq-* key exchanges I was=20 thinking of something that is truly PQ, that is, provides PFS even against= =20 quantum computers. That means something that uses Ring-LWE or supersingular= =20 isogeny DH, not something that uses FFDH or ECDH. Even if that FFDH or ECDH= is=20 slightly augmented to provide minimum of QC resistance. In other words, the intention was to make the hopeless situation survivable= =20 and provide a proper fix only after a clear winner for PQ KEX has been=20 established. Creating 3 documents is probably overdoing it. =20 > > As for technical details, I was thinking of adding a step in which the > > peers each choose a random value, GSS_Wrap it, send it to peer, > > GSS_Unwrap peers value and append their value and the peers decrypted > > value to HASH input. > That probably suffices; I would have to think a bit harder about > where there is any value gained from using such wrapped random > values as input to GSS_Pseudo_random(), or whether just passing the > HASH inputs as the prf_in input would suffice (which would mean less > data going on the wire). Yes, not requiring changes to the on-the-wire messages is a definite plus. OTOH, I'd assume that all GSS-API implementations support GSS_Wrap() and=20 GSS_Unwrap(), I don't know what's the support level for GSS_Pseudo_random(). Given the notes in RFC 7802, I see there were some problems with=20 interoperability in Kerberos... =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 --nextPart3294733.JPtQj2RNT1 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 iQIcBAABCgAGBQJZIudTAAoJEJKo0bgB0vX1kxwP/3a+tn55msog88aHcBCvpV4X zl2X35vBDTzfUxFmO4BEUDTaaODf015BV/p48nGSLS6J+9yxx6sK94/crK7kkUgL Ico5zOiTovn6v6EZEVyRfsvyroA1PvIxgSzKhPBC1o177aD8udx2sMnUbG+LBqhr kQ6hxv7fgRBMIPokemaghJMpElTvnZI7z/Mcj4QB05zhvM0aaFplw+y32MwJAbOe 5i7TUpvPjkGU51BSGyyE4C7n2glcEeAOVlAejZMRY5AD3VQFNG2bXhV3vH+SaWnA AsxEwXACJMnrvbCQ9m1b1wbX7jjX8mzeEwUB9eJX5uIgPblDcvjt3neV0ZZNiesx MU9ZWoc6CdK4MyEUgB+ubW3b+XJFryHVMkt3keeSl+Ibv5lCjAAqDvE//mWUF6a8 qAh/WBpkCpcDsq3CLRg8DPSpFsfL5RaCRr352zlTdcYvAKNxmd2CdiOUkPPp5WPT Nj6jU2qbqeZaHwdF7qFUl1k4EE22eualoKSKQH3bzA9fT0q/hlEFR+V9dsxaTqQi dd+t7+2rEni31KQ1Cbrzggb2Y6ndC8ai6sUjry0FsQHO2SwZaEw/VbwnJ5gn2Ilv YXIuJwy7neCES49X/PK2WmH9j582PVGAD0Iaj3FRW8xWk/c4iVcyXh+Cwpqn+j03 28pErm7BKRe3g8pFVzOp =Jm17 -----END PGP SIGNATURE----- --nextPart3294733.JPtQj2RNT1-- From nobody Mon May 22 19:08: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 CF076128656 for ; Mon, 22 May 2017 19:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u3HVtCzk0In for ; Mon, 22 May 2017 19:08:38 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 359B412946E for ; Mon, 22 May 2017 19:08:37 -0700 (PDT) X-AuditID: 12074423-dfbff70000004989-8e-592399a39044 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F6.B4.18825.3A993295; Mon, 22 May 2017 22:08:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4N28YCu019763; Mon, 22 May 2017 22:08:35 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4N28UZs019378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2017 22:08:33 -0400 Date: Mon, 22 May 2017 21:08:30 -0500 From: Benjamin Kaduk To: Hubert Kario Cc: curdle@ietf.org Message-ID: <20170523020830.GU39245@kduck.kaduk.org> References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com> <20170521201350.GP39245@kduck.kaduk.org> <1674834.KTPl0iozjd@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1674834.KTPl0iozjd@pintsize.usersys.redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT1108UznSoPGmvsXWhbOYLW59O8zq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGW0rtrJXvBNquL08yvsDYwbRLsYOTkkBEwk PvZ/ZO5i5OIQEljMJHH4/D42CGcjo8TB0/eZIJyrTBJXGhtZQVpYBFQlVv85zQhiswmoSDR0 X2YGsUWA7LOnOsFsZgFhiX+fW4GaOTiEBfIkFt4IBwnzAm070vMfasEVRonGXQtZIRKCEidn PmGB6NWSuPHvJVgvs4C0xPJ/HBBhbYllC1+DjecUsJXo3tAJdoKogLLE38P3WCYwCs5CMmkW kkmzECbNQjJpASPLKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJNjOCwdlHewfiy z/sQowAHoxIPr8ZjpUgh1sSy4srcQ4ySHExKorx7EpQjhfiS8lMqMxKLM+KLSnNSiw8xSnAw K4nwbssCyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKErwTZwA1Chal pqdWpGXmlCCkmTg4QYbzAA2PBKnhLS5IzC3OTIfIn2JUlBLn1QNJCIAkMkrz4HpBaUcie3/N K0ZxoFeEef+AVPEAUxZc9yugwUxAg62fyYMMLklESEk1MNpUZ0bsi5xqeUTmI9/K7ZPOuere lrjndWlq8yHRiSfifH53fiyM51x3znxy9ysGv5+bpr/e4bBTISso+HfkoeWlwQ2FTJ2rnlj8 lT6Uv3xCwskJ9S8eTve0Nyk8ESMmGZT/4mf72y+3t22tWhn2JvFJWFDcQrc1+zQays7knl19 0fPqrEhu3l9KLMUZiYZazEXFiQDxG/ecFgMAAA== Archived-At: Subject: Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 02:08:40 -0000 On Mon, May 22, 2017 at 03:27:47PM +0200, Hubert Kario wrote: > On Sunday, 21 May 2017 22:13:50 CEST Benjamin Kaduk wrote: > > On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote: >=20 > > > 2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes > > > (and > > > forget about QC-resistance - that's the current draft), or > >=20 > > But, I'm not convinced that we want to make "gss--" > > have different global semantics based on the particular group+hash > > combination; >=20 > What I was thinking, is that -sha1 ones are becoming insecure either way.= So=20 > lets make sure that the only ones that remain have the same properties (a= nd=20 > they are a superset of the -sha1 ones). Ah, I see the point better now. > > > 3). should we multiply the kex options further and provide QC-resista= nt > > > variants of all the GSSAPI kex algorithms? > >=20 > > it seems like it would make more sense to have a separate document > > that creates a new family of gss-pq-- keyex schemes, > > though probably only of the new ones from this document and not the > > SHA1 ones. >=20 > yes, using sha-1 for PQ is quite silly. For gss-pq-* key exchanges I was= =20 > thinking of something that is truly PQ, that is, provides PFS even agains= t=20 > quantum computers. That means something that uses Ring-LWE or supersingul= ar=20 > isogeny DH, not something that uses FFDH or ECDH. Even if that FFDH or EC= DH is=20 > slightly augmented to provide minimum of QC resistance. >=20 > In other words, the intention was to make the hopeless situation survivab= le=20 > and provide a proper fix only after a clear winner for PQ KEX has been=20 > established. >=20 > Creating 3 documents is probably overdoing it. But yes, 3 documents is probably overdoing it, and there is something of a desire to get a sha1 alternative out quickly so it can be implemented and those implementations have a chance to trickle out into deployment. So maybe we will just hold off until there is a winner for PQ KEX. > > > As for technical details, I was thinking of adding a step in which the > > > peers each choose a random value, GSS_Wrap it, send it to peer, > > > GSS_Unwrap peers value and append their value and the peers decrypted > > > value to HASH input. > > That probably suffices; I would have to think a bit harder about > > where there is any value gained from using such wrapped random > > values as input to GSS_Pseudo_random(), or whether just passing the > > HASH inputs as the prf_in input would suffice (which would mean less > > data going on the wire). >=20 > Yes, not requiring changes to the on-the-wire messages is a definite plus. > OTOH, I'd assume that all GSS-API implementations support GSS_Wrap() and= =20 > GSS_Unwrap(), I don't know what's the support level for GSS_Pseudo_random= (). > Given the notes in RFC 7802, I see there were some problems with=20 > interoperability in Kerberos... Yeah, it is not as widely implemented/adopted as the original GSS APIs. But there is software out there actually using it, commercial software even, so there has been some progress on that front. The two big open-source C Kerberos implementations have had it for a few years (MIT and Heimdal), but I don't have a sense for whether (e.g.) Java or the various closed-source GSSAPI implementations have picked it up. -Ben From nobody Tue May 23 02:29:38 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7B2129A8E; Tue, 23 May 2017 02:29:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Winter To: Cc: draft-ietf-curdle-cms-ecdh-new-curves.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149553176028.29418.18414274218431090509@ietfa.amsl.com> Date: Tue, 23 May 2017 02:29:20 -0700 Archived-At: Subject: [Curdle] Opsdir last call review of draft-ietf-curdle-cms-ecdh-new-curves-07 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, 23 May 2017 09:29:20 -0000 Reviewer: Stefan Winter Review result: Has Nits Nits: * 2.1 starts with "... based on a one-way hash function described in ANS X9.63 [X963]." s/ANS/ANSI/ * Chapter 7 defines six OIDs (secg-scheme 11 1...3 and smime-alg TBD1...3) and also includes the base OIDs under which these new OIDs are attached (secg-scheme and smime-alg). Those two are not defined in this document, but the text in chapter 7 suggests so. Maybe it would be a bit clearer if the text stated explicitly which of the OIDs in the chapter are NEW, and which ones already exist and are provided for reference/context. From nobody Tue May 23 03:20: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 F37BA129466 for ; Tue, 23 May 2017 03:20:18 -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 Z9PVQ0WlefCJ for ; Tue, 23 May 2017 03:20:17 -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 0632C124C27 for ; Tue, 23 May 2017 03:20:17 -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 9367B8047D; Tue, 23 May 2017 10:20:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9367B8047D 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 9367B8047D Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 373EC5C541; Tue, 23 May 2017 10:20:16 +0000 (UTC) From: Hubert Kario To: Benjamin Kaduk Cc: curdle@ietf.org Date: Tue, 23 May 2017 12:20:09 +0200 Message-ID: <8089232.lOomSp7LcR@pintsize.usersys.redhat.com> In-Reply-To: <20170523020830.GU39245@kduck.kaduk.org> References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <1674834.KTPl0iozjd@pintsize.usersys.redhat.com> <20170523020830.GU39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1714443.sBf9JYRMPM"; 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]); Tue, 23 May 2017 10:20:16 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:20:19 -0000 --nextPart1714443.sBf9JYRMPM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 23 May 2017 04:08:30 CEST Benjamin Kaduk wrote: > On Mon, May 22, 2017 at 03:27:47PM +0200, Hubert Kario wrote: > > On Sunday, 21 May 2017 22:13:50 CEST Benjamin Kaduk wrote: > > > On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote: > > > > 3). should we multiply the kex options further and provide > > > > QC-resistant > > > > variants of all the GSSAPI kex algorithms? > > >=20 > > > it seems like it would make more sense to have a separate document > > > that creates a new family of gss-pq-- keyex schemes, > > > though probably only of the new ones from this document and not the > > > SHA1 ones. > >=20 > > yes, using sha-1 for PQ is quite silly. For gss-pq-* key exchanges I was > > thinking of something that is truly PQ, that is, provides PFS even agai= nst > > quantum computers. That means something that uses Ring-LWE or > > supersingular > > isogeny DH, not something that uses FFDH or ECDH. Even if that FFDH or > > ECDH is slightly augmented to provide minimum of QC resistance. > >=20 > > In other words, the intention was to make the hopeless situation > > survivable > > and provide a proper fix only after a clear winner for PQ KEX has been > > established. > >=20 > > Creating 3 documents is probably overdoing it. >=20 > But yes, 3 documents is probably overdoing it, and there is > something of a desire to get a sha1 alternative out quickly so it > can be implemented and those implementations have a chance to > trickle out into deployment. So maybe we will just hold off until > there is a winner for PQ KEX. Ease of upgrade to SHA-2 was the primary reason we decided to propose the=20 simple version of the draft. > > > > As for technical details, I was thinking of adding a step in which = the > > > > peers each choose a random value, GSS_Wrap it, send it to peer, > > > > GSS_Unwrap peers value and append their value and the peers decrypt= ed > > > > value to HASH input. > > >=20 > > > That probably suffices; I would have to think a bit harder about > > > where there is any value gained from using such wrapped random > > > values as input to GSS_Pseudo_random(), or whether just passing the > > > HASH inputs as the prf_in input would suffice (which would mean less > > > data going on the wire). > >=20 > > Yes, not requiring changes to the on-the-wire messages is a definite pl= us. > > OTOH, I'd assume that all GSS-API implementations support GSS_Wrap() and > > GSS_Unwrap(), I don't know what's the support level for > > GSS_Pseudo_random(). Given the notes in RFC 7802, I see there were some > > problems with > > interoperability in Kerberos... >=20 > Yeah, it is not as widely implemented/adopted as the original GSS > APIs. But there is software out there actually using it, commercial > software even, so there has been some progress on that front. The > two big open-source C Kerberos implementations have had it for a few > years (MIT and Heimdal), but I don't have a sense for whether (e.g.) > Java or the various closed-source GSSAPI implementations have picked > it up. At least one Java library claims that it supports it https://github.com/ cconlon/kerberos-java-gssapi and given it's a MIT wrapper, it should have n= o=20 problems interoperating. I couldn't find anything for the MS implementation... Anyway, the PQ stuff will require new crypto implementations, so we probabl= y=20 should be OK with requiring the GSS_Pseudo_random() to go along with it. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1714443.sBf9JYRMPM 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 iQIcBAABCgAGBQJZJAzZAAoJEJKo0bgB0vX1lCMQAJ+rnsUNybpl8PheSt5yH0Wg dtYIlMST9nLW0mdOSe2jKQcTbpCfs7pnxQtd9LfTc12EEMxbeZpxuZVeTiyWkGTd EB6hAMAzasPvgoOxKxlKNyJMsJaxsfA1ew5oqzqztGHo0n3HWWE57b1fkKgqHeYJ 6zUP3wW0fxPoUp+1bmegg+ZGb0p/1keECuVErb3kvI9zMjs10WfD3Sc4GADqfmH/ Ocw41TTnZRK47U/r6LZcpX0Duqfa9fd9fcYFzwApyk0gxphRxe/8B2XkYuwc1knI 3AKhkgmBAQl+w0lHm2LXeANfBkb8iqrHhZs8CRwAm+3BgvvkV/Oqa2ZsiBkXU8hm m0jqZcOjJWTjXsqIRA3LQy2uxFlTOJaGWYUgIcDQdEfzcCa+1fWQGW0a0O8s2KsI 5FDJEkWJWYuHwICDy8GLOTVsy1gGAlbAl2mPO4r1pCe2jn7WqZ1yPfofoCOCaWec r70azc5gjKOvLoiqKmSXhG1J61J8tfbwpVXmxUiKopQGgK60PiunMjHhDWQEIZd3 A2M/M6HWa9pahR3Ctsu5xYPwHfD5XSzmgiSEPwIFK1Wh9IqOd3sB0fbnVHJi/mCM 56CSVAjMZOvDGWJ98VN4eC3R1CcMblmiR4j3lddkSi/G3EGcqYjTrVBBnOs3UXnJ nU24cs0kYc+iYx9806FJ =88gl -----END PGP SIGNATURE----- --nextPart1714443.sBf9JYRMPM-- From nobody Thu May 25 03:57:18 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 B41F012946B; Thu, 25 May 2017 03:57:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-curdle-cms-ecdh-new-curves.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149570983670.8681.5001417855088402577@ietfa.amsl.com> Date: Thu, 25 May 2017 03:57:16 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-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, 25 May 2017 10:57:17 -0000 Reviewer: Roni Even Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-curdle-cms-ecdh-new-curves-?? Reviewer: Roni Even Review Date: 2017-05-25 IETF LC End Date: 2017-05-28 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as a standard track RFC Major issues: Minor issues: Nits/editorial comments: In general it was easy to read and follow. Maybe it will be good to repeat in section 3.2 the definition of KeyAgreeRecipientInfo . This is done is section 2 for ECC-CMS-SharedInfo but it is not crucial. 1. There is no ToC 2. In section 2.2 fourth paragraph "is used two places" - "in two .." From nobody Thu May 25 17:33:26 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2916127775 for ; Thu, 25 May 2017 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRV4QXAap_ju for ; Thu, 25 May 2017 17:33:22 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873F11272E1 for ; Thu, 25 May 2017 17:33:22 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id 99so91907102lfu.1 for ; Thu, 25 May 2017 17:33:22 -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=aV0QOyk0x35snIDU3t192F1djwe9IqNuDSuLznZYZEE=; b=HLyj49IL+nv7qr33GejiJsCl7D2cm1hchRRfY1pDFqAA+99MK4XuGfzf2sEk0u85Lb zzggE9lvHHp7fDynWLbiya6d9OypgJ1oNo5dO4IFdis5rNE/+cfT57nN3dMvoaKWIYXi mIV4TNQnVAeOTjClhEViVNBYhbxboo5LBhtUuY1lbuk76xzvIpgRizJmmiaiHYLuo9Ak /1ISzozkMdWEsJdyoNwJNELe+gx0kZqUjEaPKvzsbxwsvmJKGvpg8/4Ap5bbW69CorEh SvKY/Hxom98t3jLpUDTE8GijsGtAD3fqmXbbjbYwU1dE9qjWfQU83onFLdnqmMeMgnme J85w== 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=aV0QOyk0x35snIDU3t192F1djwe9IqNuDSuLznZYZEE=; b=QyzkMVOIYAOOs/GpF7YWLt+tOiZRPk/T8krD64gUi2gSBhL6Gw5iTRpjawgXJrHMjB aHzMvDAD7Rxr0+M8VntI4QNEDPTbsnM50p/TrusndI65z8HYjzFPC4VRrvUUYmHBfQhv qf8fEVRBJvyOH/8egywiT5CVhusrIOiEmroBcfHKJQzDK5tAbo5C1eXI1qGmoqz1O2MH U6icg4P6TGpwUrDrTi6ALf5BmS+KpTUpWJ9RuWNJhmQfeOvpsqx+RvpFNdyl6sN8KasT 0QqSyny6tF6E2l0rKLLyEbZ4TKRbUGhJz4XWWMyyCQn9zmBggqYdNeOCCqAo7S8Y310W kqNw== X-Gm-Message-State: AODbwcAcsq/LzIRtZZGoV5WTLLomsLlr0cy630uqZJLRniCsWVL2C0s5 b4ncj6GEbsH6xPFSyR/EWwvI4MgTIg== X-Received: by 10.25.208.14 with SMTP id h14mr10201088lfg.174.1495758800899; Thu, 25 May 2017 17:33:20 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Thu, 25 May 2017 17:33:20 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> References: <149426463707.11242.13594573268237847336.idtracker@ietfa.amsl.com> <007b01d2c821$5f8eb670$1eac2350$@augustcellars.com> <20170509051032.GZ30306@kduck.kaduk.org> <20170509055301.GB30306@kduck.kaduk.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BD8F66@eusaamb107.ericsson.se> From: Daniel Migault Date: Thu, 25 May 2017 20:33:20 -0400 X-Google-Sender-Auth: OfntDXcIms6ohPyZq5R8HFYl8_k Message-ID: To: Eric Rescorla , Benjamin Kaduk Cc: Jim Schaad , Martin Thomson , curdle Content-Type: multipart/alternative; boundary="001a11412d3cff53ca0550627b25" Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-schaad-curdle-oid-registry-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 00:33:25 -0000 --001a11412d3cff53ca0550627b25 Content-Type: text/plain; charset="UTF-8" Hi, Thank you all for reviewing the draft and expressing your opinion on the adoption of the draft. None opposed the adoption, and a reasonable number of people supported its adoption. The draft is adopted. as a WG document. Yours, Daniel On Tue, May 9, 2017 at 2:35 PM, Daniel Migault wrote: > Hi, > > > > This is a call for adoption of the following draft: > https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > > > If you believe this draft should not be adopted as a WG document please > let us know by May 23. > > Please also provide your reviews of the draft. > > > > Yours, > Daniel > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11412d3cff53ca0550627b25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you all for reviewi= ng the draft and expressing your opinion on the adoption of the draft. None= opposed the adoption, and a reasonable number of people supported its adop= tion. The draft is adopted. as a WG document.

Yours,
Daniel

On Tue, May 9, 2017 at 2:35 PM, Daniel Migault <daniel.migault@= ericsson.com> wrote:

Hi,

=C2=A0

This is a call for adoption of the following draft: https://datatracker.ietf.org/doc/draft-sc= haad-curdle-oid-registry/

=C2=A0

If you believe this draft should not be adopted as a= WG document please let us know by May 23.

Please also provide your reviews of the draft.

=C2=A0

Yours,
Daniel

=C2=A0


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

--001a11412d3cff53ca0550627b25-- From nobody Thu May 25 17:40:38 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9B129BB6; Thu, 25 May 2017 17:40:36 -0700 (PDT) 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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149575923677.8590.1402584814812178774.idtracker@ietfa.amsl.com> Date: Thu, 25 May 2017 17:40:36 -0700 Archived-At: Subject: [Curdle] The CURDLE WG has placed draft-schaad-curdle-oid-registry in state "WG Document" X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 00:40:37 -0000 The CURDLE WG has placed draft-schaad-curdle-oid-registry in state WG Document (entered by Daniel Migault) The document is available at https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ From nobody Thu May 25 20:53: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 F104D129AE0 for ; Thu, 25 May 2017 20:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, 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 oaBeEGovMyaJ for ; Thu, 25 May 2017 20:53:34 -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 B818112751F for ; Thu, 25 May 2017 20:53:34 -0700 (PDT) X-AuditID: 1209190e-641ff70000001b60-5d-5927a6bc6d28 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.8E.07008.CB6A7295; Thu, 25 May 2017 23:53:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v4Q3rVXN018333; Thu, 25 May 2017 23:53:32 -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 v4Q3rSaO012544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 May 2017 23:53:30 -0400 Date: Thu, 25 May 2017 22:53:28 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: curdle@ietf.org Message-ID: <20170526035327.GA39245@kduck.kaduk.org> References: <20170518021005.GK39245@kduck.kaduk.org> <950c6ace-d34e-108c-a3db-d1bdb89a2af4@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <950c6ace-d34e-108c-a3db-d1bdb89a2af4@mit.edu> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrLt3mXqkweRPMhZbF85idmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoS7lQX3WSq29Bg0MD5n7mLk5JAQMJG4fruNqYuRi0NIYDGT RMvfT6wQzkZGibUbJrBDOFeZJOZ8XQzWwiKgKtG28gUTiM0moCLR0H0ZLC4ioCjxbNVcFhCb WUBY4t/nVrAaYQFfiW3vbrOD2LxA6zpnvIEa2sso8f30W6iEoMTJmU+gmrUkbvx7CdTMAWRL Syz/xwFicgpYS7w+Hw9SISqgLPH38D2WCYwCs5A0z0LSPAuheQEj8ypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdY73czBK91JTSTYzgcJTk28E4qcH7EKMAB6MSD++Ge2qRQqyJZcWVuYcYJTmY lER59azVI4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8G5NB8rxpiRWVqUW5cOkpDlYlMR5xTUa I4QE0hNLUrNTUwtSi2CyMhwcShK8M5cCNQoWpaanVqRl5pQgpJk4OEGG8wANdwep4S0uSMwt zkyHyJ9i1OVo+rDlC5MQS15+XqqUOK8ASJEASFFGaR7cHFAakcjeX/OKURzoLWHe7yBVPMAU BDfpFdASJqAlrneVQZaUJCKkpBoYl1S/E+z3+yAjeHWaY+gB8+1q9yruC2cGS/5cPvXmFrlF J8PE9m84GWx4w6oxfd2tT6IdV9bW77sufFDruY238QWLk9v8OD+uZ/2Vp6AnkL/5tLXwEvcU u4xfRkV5amdt5jlFb2i84hTFUx16MGH5vEdP3/tqvPEOFF97d5rqgmWKLdMbDqzmUmIpzkg0 1GIuKk4EAB5rhf/+AgAA Archived-At: Subject: Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 26 May 2017 03:53:36 -0000 On Wed, May 17, 2017 at 11:26:33PM -0400, Greg Hudson wrote: > On 05/17/2017 10:10 PM, Benjamin Kaduk wrote: > > Hi Greg, > > > > Thanks for the review. Could you clarify which version you > > reviewed? > > (https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 > > or > > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-00 > > ?) > > I think the former. I took a look at > draft-ietf-curdle-des-des-des-die-die-die-00 just now, and it looks the > same to me. Thanks. > I do see a typo "implemneted" in section 6.2. Staged a fix. -Ben From nobody Thu May 25 21:28: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 AC51B1293D8; Thu, 25 May 2017 21:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 NIlmVBVLE8qZ; Thu, 25 May 2017 21:28:53 -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 77366126B71; Thu, 25 May 2017 21:28:53 -0700 (PDT) X-AuditID: 1209190e-533ff700000074e2-12-5927af021840 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 70.92.29922.20FA7295; Fri, 26 May 2017 00:28:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4Q4SnTI029247; Fri, 26 May 2017 00:28:50 -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 v4Q4SjAS019271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2017 00:28:48 -0400 Date: Thu, 25 May 2017 23:28:45 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , "curdle-chairs@ietf.org" , "'curdle'" Message-ID: <20170526042845.GB39245@kduck.kaduk.org> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433@eusaamb107.ericsson.se> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6nrsu8Xj3S4GKPjMXMng3MFlsXzmK2 mDJ9D5vF064jTA4sHr++XmXzWLLkJ1MAUxSXTUpqTmZZapG+XQJXRt8uh4JZahVbZik1MH6U 7WLk5JAQMJE4vqaZtYuRi0NIYDGTxNWTTxghnI2MEv+WnWWBcK4ySeye2cLexcjBwSKgKtEz hQekm01ARaKh+zIziC0iYCDxcsJONpB6ZoELjBL77yxnBUkICzhIrPp/hB3E5gVad33SOjBb SMBX4sXzl0wQcUGJkzOfsIDYzAJaEjf+gcQ5gGxpieX/OEBMTgE/ic3T1EEqRAWUJf4evscy gVFgFpLmWUiaZyE0L2BkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREUtJyS fDsYJzV4H2IU4GBU4uHdcE8tUog1say4MvcQoyQHk5Io7/R16pFCfEn5KZUZicUZ8UWlOanF hxglOJiVRHh3rgTK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvO4g QwWLUtNTK9Iyc0oQ0kwcnCDDeYCGt4LU8BYXJOYWZ6ZD5E8xKkqJ815eC5QQAElklObB9YKS ikT2/ppXjOJArwjzsoO08wATElz3K6DBTECDXe8qgwwuSURISTUwchXM4Xi9Kv/58grFd0Z6 j44JdZ89+K0754COUozHDcb3XG9Uj895Ys7Uvt3jSKLdIfu9J7Vdg7O2t052i92zO+7w7zk6 d0Lst20/+lnx7fybU+M++/NI13NVW6tc5T1YszVz2o4lBnoTlpicuZ9uf2ODlmeg7oJ3xbZh WqG/5r3tzX4z7fq5OiWW4oxEQy3mouJEAFHZeqMFAwAA Archived-At: Subject: Re: [Curdle] review of draft-ietf-curdle-des-des-des-die-die-die 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, 26 May 2017 04:28:56 -0000 On Thu, May 18, 2017 at 02:35:24AM +0000, Daniel Migault wrote: > Hi, > > The draft seems to me quite ready. Please find some small comments. > > > 1. Updates / obsoletes should be mentioned in the header, abstract and intro. Gosh, for all the times I've reminded other people about this, I feel silly having missed it. > > 1. Status: wouldn't standard track be more appropriated ? Yes, that's another long-standing issue I failed to fix when preparing the more recent updates. Though, RFC 6649 is actually a BCP, so maybe that is better than standards-track. I'll go with bcp in my working copy, but of course we can revise it as needed. > Nits: > > Section 5.2 > > > > to the has function > > section 5.4: > > > TGT needs to be defined. Fixed. > > """ > > It is now believed that all machines that might be broken by disabling RC4 are unsupported, and concerns about breaking them will be reduced. > > """ > > > > I see this sentence as reflecting a support team point of view. If > an application runs on W2003 and save lifes, I prefer not breaking > it. > > > > I believe the issue is that an important aspect of support is > addressing vulnerabilities. As patches are not provided for these > versions, these systems becomes too vulnerable and authentication > with Kerberos may provide limited protection. In such situation, > could Kerberos be disabled, and alternate authentication may be > used. Kerberos might be the preferred way to perform > authentication but what would be the other ways. The typical use > case I see is a that new client will not be able to connect the > service. I hardly see KDC, Services being updated while client are > not updated. I am fine clearly saying that upgrading to newer > version is recommended. Because of the nature of Kerberos deployments, with many shared secrets across different parties, it is generally difficult to make sweeping changes quickly. So, I do not think the effect of this document will be a rush for everyone to immediately remove the affected shared keys; many will continue to exist for a long time. Probably a good mental model for the desired transition is that new clients being installed stop using it, and KDCs/servers start considering turning them off, presumably with various exceptions as appropriate. Entirely new realms would hopefully not use them at all, but existing ones would likely continue to have them enabled for quite some time. As a rough guideline, for MIT Kerberos we tend to think of having to wait ten years before we can assume that some new feature has sufficiently universal deployment that we should expect it to "always" be present. > > > OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. If the status is SHOULD NOT, it gives time for the transition. In that case comment above may not require so detailed explanations. Then, do we have recommendation for the deprecation, such as specific message, logs...? I think I initially wanted to do MUST NOT (in the mindset that adoption of this standard will be gradual, that is still consistent with the expected rollout procedure), but went with SHOULD NOT for consistency with RFC 6649. However, the generation of that document predates my involvement, so I don't know offhand what went into getting consensus for the SHOULD NOT. > > Section 7. > > If SHOULD NOT is specified, maybe we should mention that the status is expected to move to MUST NOT. That seems consistent with a BCP designation, in that for now it is SHOULD NOT, but the next update will make it MUST NOT. If we target BCP status, I don't feel a particular need to mention it, but if we did, I would probably do it at the end of the "Recommendations" section as: Future versions of this document are expected to change these recommendations from SHOULD NOT to MUST NOT. > Nits from the datatracker: > > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > (Using the creation date from RFC3961, updated by this document, for > RFC5378 checks: 2004-02-11) > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) This document does not contain any content from RFC 3961, so I think this one can be ignored. Thanks for all the comments! -Ben From nobody Thu May 25 21:49: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 96E8D126B71 for ; Thu, 25 May 2017 21:49:19 -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 pZjAOAsLPSmM for ; Thu, 25 May 2017 21:49:15 -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 BB4E4126D74 for ; Thu, 25 May 2017 21:49:14 -0700 (PDT) X-AuditID: 1209190e-51bff700000074e2-9e-5927b3c9d1a3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 57.34.29922.9C3B7295; Fri, 26 May 2017 00:49:13 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4Q4nC2v030543; Fri, 26 May 2017 00:49:12 -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 v4Q4n8xS022979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2017 00:49:11 -0400 Date: Thu, 25 May 2017 23:49:08 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: curdle@ietf.org Message-ID: <20170526044907.GC39245@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nrntys3qkQfMKDYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+yPl6wF3cIVe4/fZ29gnMPfxcjBISFgIrF4PVcXIxeHkMBi JokzvXtYIZyNjBJz9x5gg3CuMkm8aDjD1MXIycEioCoxcd0RNhCbTUBFoqH7MjOILSKgKPFs 1VwWEJtZQFji3+dWsHphAV+Jbe9us4PYvEDbdn3ewAiyWUjAUOLDCRGIsKDEyZlPoFq1JG78 e8kEUsIsIC2x/B8HSJhTwEji2KFzrCC2qICyxN/D91gmMArMQtI9C0n3LITuBYzMqxhlU3Kr dHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYLCkVOSbwfjpAbvQ4wCHIxKPLwb7qlFCrEm lhVX5h5ilORgUhLlnb5OPVKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/OlUA53pTEyqrUonyY lDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCd+cmoEbBotT01Iq0zJwShDQTByfIcB6g 4ftBaniLCxJzizPTIfKnGBWlxHnfbARKCIAkMkrz4HpB6UIie3/NK0ZxoFeEeQ+AtPMAUw1c 9yugwUxAg13vKoMMLklESEk1ME4JidD0zOkteiJ7eRVb83XFftlbj830ND7arfbgCWXbdyNS 7jvrPYl7+3dP6q0xjXqxQ3Fex5ss1p8B7mzCfXM26TWekykzbtZ+2zxDyUqqh3mJQPAG97iV vIpvn16/FuwsNPtZrdwkxzuuRqr7vggsfJO8sqVLkuurpkxM3U57+7rfy52uK7EUZyQaajEX FScCANleBNryAgAA Archived-At: Subject: Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 26 May 2017 04:49:19 -0000 On Wed, May 17, 2017 at 11:54:03AM -0400, Greg Hudson wrote: > I have reviewed this draft and have no blocking objections. Some > non-blocking, editorial notes: > > Interoperability concerns are listed last for RC4, but second out of > three subsections for DES3. To some extent the section structure for the two ciphers are completely different, but I do see some argument for putting interop concerns last in both cases; I'll make that change. > Section 5.2, "Modern encryption types such as [...] use" should have a > comma before "such as" and before "use". I think this is technically a stylistic matter, but my normal tendency is to overuse commas (so that I have to consciously correct for it); I'm happy to put them back. > Section 5.2, "It is also best practice when [...], to" should have a > comma before "when". Also, "it is also best practice" doesn't seem > right. Sure, these commas need to come in pairs. Is dropping to just "it is best practice" enough of an improvement to make you happy? (There's not really a preceeding instance that would make the "also" useful.) > Section 5.3, "Because [...], this means that these application servers > also possess" should omit "this means that". I would also remove the > parenthetical for that sentence. Done. > Section 5.4, "cross-realm situations" should perhaps be "cross-realm > deployments". Sure. > Section 6, in "ample justification for deprecating their use", "their" > appears to refer back to "The flaws", which doesn't seem quite right. I think "their" was trying to be representing the plural "triple-DES based encryption types". That's rather clunky, so I'll just go for "deprecating its use", which I think is sufficiently unambiguous. > Section 6, "blocksize" should be "block size". Yup. > Section 6.1, "[nfold] is known not to provide effective mixing of the > input bits" is not backed up by a reference. (I don't know of a > reference.) I don't know of a reference, either. I don't really want to drop down to a weaker statement like "not expected to provide effective mixing", as I have a vague memory of someone telling me that (e.g.) it was hard to get things with the high bit set when an ASCII password is used. If the lack of reference becomes problematic for IETF/IESG review we can certainly revisit the question (and try to get something closer to primary data). -Ben From nobody Fri May 26 08:11: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 33C2212E056 for ; Fri, 26 May 2017 08:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ish2lI26LqzL for ; Fri, 26 May 2017 08:11:22 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EEF129AE5 for ; Fri, 26 May 2017 08:11:22 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 99so7660866lfu.1 for ; Fri, 26 May 2017 08:11:22 -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=rxQMWOg9qX5cXRxFGg+yNQxJO+/YE6+vGzSvXMxkiHg=; b=LEKTBr/Q2TRC5sbrJWt7CjsSVwOY0V9/Obbhs51MOWrwPL0Z8doqC4qvxJb3/9cDyK HgDoTtyAaxqImxDAzl8ii2gN5U/+59XC1xxM36uinPBvieVM0hkfGLLnoNv1J4uiLRxn 9r47ShQ82miF0V8E3H7vRyL0ckvyR8trhkb6dtRl82O1NRt1jVSktNpNb9ZwYwTjVcC4 QKRCFWan6qB+pQ6ylCe23Vi7RzaTo6+cd6inSpFvCEbOSxSt/d85w3eGIOknCrzn1eWQ 01RlRDVFX2/mLmU72a21Q66Gmstm9HSOQr1+PefyOTuSokzSMb8YsGwgbmcox7kVCFdT YHfA== 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=rxQMWOg9qX5cXRxFGg+yNQxJO+/YE6+vGzSvXMxkiHg=; b=b9Pb3WTv/P9cSg+dxSltxFfT4h7cSzHvEme2C3WJAKcN+xaZ308BIqf3XC7D5SxJ5c uKBn5ahhCBQ1Caa/NCkq4Z+2MR7hQiPrv/IJNDOI2PThh00WdmpNO4yRCiIANfiTpXM1 01VqIRJIfzc0hFW+D2jNQj6ov6cEo1dQyeEjqysSuWXqeX9uxrINTtRXFf6vKGuUQl2S 8H3FeAE0PMfrIUJIDpyCyi+l4Q0yRQC/Htju+2T6lEKwha8VCW9cw0LGixwscBmwxZbi Ny3/SRIsOTRX5+Xu+Qznu8Y3apxoZfsz4jzTROvaOntQolssjnZ2fgHIOhRRBme/vzEL pWjw== X-Gm-Message-State: AODbwcAkKfMytig8pF5VnA6ttZNIXVwxdl8PC4ML7vCsNwhOvQqPLb3d lz7MAruDZhtG8sNHkYTkFyjvPjiQF2Fd X-Received: by 10.25.228.197 with SMTP id x66mr729391lfi.145.1495811480183; Fri, 26 May 2017 08:11:20 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 26 May 2017 08:11:19 -0700 (PDT) From: Daniel Migault Date: Fri, 26 May 2017 11:11:19 -0400 X-Google-Sender-Auth: yYJbzz2Iu6cs4XsNGOjorOKIlOU Message-ID: To: curdle Content-Type: multipart/alternative; boundary="94eb2c0e7d88ed6b2505506ebfaf" Archived-At: Subject: [Curdle] draft-ietf-curdle-rsa-sha2 shepherd write-up/nits 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, 26 May 2017 15:11:24 -0000 --94eb2c0e7d88ed6b2505506ebfaf Content-Type: text/plain; charset="UTF-8" Hi, The draft draft-ietf-curdle-rsa-sha2 is almost ready to be sent to IESG. I have found some minor nits to be addressed to complete the shepherd write up. The shepherd write up is available [here]. Feel free to comment in the next few days. nits: Please mention in the section "1. Overview and Rationale": This memo updates RFC 4252 and RFC 4253. section 3.2 As all terms user_name, service_name... are not defined in the document, I suggest to replace: OLD: For example, an SSH "publickey" authentication request using an "rsa-sha2-512" signature would be properly encoded as follows: NEW: For example, as defined [RFC4252] and [RFC4253], an SSH "publickey" authentication request using an "rsa-sha2-512" signature would be properly encoded as follows: Yours, Daniel [here] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/shepherdwriteup/ --94eb2c0e7d88ed6b2505506ebfaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The draft draft-ietf-curdle-rs= a-sha2 is almost ready to be sent to IESG. I have found some minor nits to = be addressed to complete the shepherd write up.

The shepherd write u= p is available [here]. Feel free to comment in the next few days.

<= /div>nits:
Please mention in the section "1.=C2=A0 Overvi= ew and Rationale":

This memo updates RFC 4252 and RFC 4253.=C2= =A0

section 3.2

As all terms user_name, service_name... are= not defined in the document, I suggest to replace:

OLD:
For exam= ple, an SSH "publickey" authentication request using an
"= rsa-sha2-512" signature would be properly encoded as follows:

N= EW:
For example, as defined [RFC4252] and [RFC4253], an SSH "public= key" authentication request using an "rsa-sha2-512" signatur= e would be properly encoded as follows:

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

[here= ] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2= /shepherdwriteup/=C2=A0
--94eb2c0e7d88ed6b2505506ebfaf-- From nobody Fri May 26 12:02: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 C01D3129B46 for ; Fri, 26 May 2017 12:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZaN45dqweDc for ; Fri, 26 May 2017 12:02:15 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 EE530129B51 for ; Fri, 26 May 2017 12:02:14 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id m18so10582227lfj.0 for ; Fri, 26 May 2017 12:02:14 -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=mrxInL2km3PRZ0fbUl7lOAE96Ce2rKeZjcQhlK+hG/s=; b=qKy9AnS1oTj+vRKXIY/oFCyMz6/0BMC9z+HqR3zczgUrgmsQQucTO+Jy8xiRje4P3Y OAlvlA2P0xR2uVkG2LHXHbYEqm38L9LWD4dbNmCouDUXILxQ4vfYieASb1uxxCYMWrE4 YyQHpsmWoH81ZZK1D+AujdU+eh8nvKN9IW0gIOj92F4S2gfXQkv1q5gJUmNuy7ZkTvv5 8G1wwlDHimqdkZJ8y+bHVQVPbaN7VH5vsHEZXhasEIs/ekq4sRGD45eBWYI5awihmVe9 dM8ZMvlDOZKzHFyLMDRZWya5zvuGpVrF8ifItIi+uo2XXQKdQ/iMMiXCq9/5fi1jScMD o5oQ== 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=mrxInL2km3PRZ0fbUl7lOAE96Ce2rKeZjcQhlK+hG/s=; b=J/9Hn1T96Nu2hSNBFeBnKSRY5iRaS31Kg1F6wSLYNl1213omCn9erGl5vjOOMHQcQD wwSvDjpk9uDURTex9JJNAULxz8j81aujwzCv9MAgfdMY69MTGTbd/i95jV3B01gQBk8t BJShSTWrXwTr2+rHgQ8CXEXuuE3frIMr1GgZ7RiqX08Iv1u6owK/ABaeWqeZsVA/PFJK QD9aBNCvgOzHVEMLjeMtNmGzt67IwLVFsZaAx+Y8Wo4T0q00srJaVmwqOG9oB3ZJYQ5G CqlOxBPVaUjhw1Nm1E4TK9XqMs+nxOuDD5pQ5q9LaMMFkKthn05Nl2Agl40Lt/AwHn63 1X6g== X-Gm-Message-State: AODbwcD9jhtoug74+F5o4krjxQBIG0yU4Ulx9m+pBsB3x//wIr8q+mDk yKWucjMDO1RR0bCv4ZXUgVEHaaXn8NPU X-Received: by 10.25.80.79 with SMTP id z15mr951265lfj.142.1495825332254; Fri, 26 May 2017 12:02:12 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 26 May 2017 12:02:11 -0700 (PDT) From: Daniel Migault Date: Fri, 26 May 2017 15:02:11 -0400 X-Google-Sender-Auth: zBdyHMsNMVe4n1He6tEbaXtKmBo Message-ID: To: curdle Content-Type: multipart/alternative; boundary="94eb2c1cb0b0933f3a055071f913" Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-ext-info shepherd write-up/nits 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, 26 May 2017 19:02:17 -0000 --94eb2c1cb0b0933f3a055071f913 Content-Type: text/plain; charset="UTF-8" Hi, Thank you everyone for the reviews, and Denis for bringing the consensus over this document. The draft-ietf-curdle-ssh-ext-info is almost ready to be sent to IESG. I have found some minor nits to be addressed to complete the shepherd write up. The shepherd write up is available [here]. Feel free to comment in the next few days. nits: section 1 Overview and Rationale Could you please add the following sentence, to comply with the shepherd writte-up: This memo updates RFC 4252, RFC 4253, and RFC 4254. In section 3.1. """In this extension, a server SHOULD enumerate ALL public key algorithms""" I am fine with the text, but ALL is not a normative word. I will try to clarify that. I am also wondering if the reason for SHOULD instead of a MUST is not that existing implementation do not follow the standard. If that is the reason, having MUST may be preferred with the explanation following the recommendation. RFC6919 MUST (BUT WE KNOW YOU WON'T) seems to me appropriated for that. Yours, Daniel [here] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/shepherdwriteup/ --94eb2c1cb0b0933f3a055071f913 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you everyone for the reviews,= and Denis for bringing the consensus over this document. The draft-ietf-cu= rdle-ssh-ext-info is almost ready to be sent to IESG. I have found some min= or nits to be addressed to complete the shepherd write up.

The sheph= erd write up is available [here]. Feel free to comment in the next few days= .

nits:

section 1 Overview and Rationale

C= ould you please add the following sentence, to comply with the shepherd wri= tte-up:

This memo updates RFC 4252, RFC 4253, and RFC 4254.

I= n section 3.1.

"""In this extension, a server SHOULD= enumerate ALL public key algorithms"""

I am fine wit= h the text, but ALL is not a normative word. I will try to clarify that.
I am also wondering if the reason for SHOULD instead of a MUST is not= that existing implementation do not follow the standard. If that is the re= ason, having MUST may be preferred with the explanation following the recom= mendation. RFC6919=C2=A0 MUST (BUT WE KNOW YOU WON'T) seems to me appro= priated for that.

Yours,
Daniel


--94eb2c1cb0b0933f3a055071f913-- From nobody Fri May 26 12:41:55 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CAC1274D0 for ; Fri, 26 May 2017 12:41:51 -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=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 baTyJ4L_mlLJ for ; Fri, 26 May 2017 12:41:51 -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 06816129B5A for ; Fri, 26 May 2017 12:41:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 510AA300526 for ; Fri, 26 May 2017 15:34:32 -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 YNgt5uN0y6RC for ; Fri, 26 May 2017 15:34:30 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2DC0C30029C; Fri, 26 May 2017 15:34:30 -0400 (EDT) From: Russ Housley Message-Id: <2FCD7FC6-1CF6-4B4B-8D2E-6043EC6FE268@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA2DDDBE-2388-4EAD-832E-E31DE0D1D28D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 26 May 2017 15:34:29 -0400 In-Reply-To: <149553176028.29418.18414274218431090509@ietfa.amsl.com> Cc: ops-dir@ietf.org, curdle , IETF To: Stefan Winter References: <149553176028.29418.18414274218431090509@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Opsdir last call review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 19:41:52 -0000 --Apple-Mail=_EA2DDDBE-2388-4EAD-832E-E31DE0D1D28D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 23, 2017, at 5:29 AM, Stefan Winter = wrote: >=20 > Reviewer: Stefan Winter > Review result: Has Nits >=20 > Nits:=20 >=20 > * 2.1 starts with "... based on a one-way hash function described in > ANS X9.63 [X963]." s/ANS/ANSI/ The American National Standards Institue (ANSI) is an organization. See = https://www.ansi.org/ . American National Standards (ASN) are documents. In this case, ANS = X9.63 is being referenced. I will expand ANS to American National Standard to avoid future = confusion. >=20 > * Chapter 7 defines six OIDs (secg-scheme 11 1...3 and smime-alg > TBD1...3) and also includes the base OIDs under which these new OIDs > are attached (secg-scheme and smime-alg). Those two are not defined in > this document, but the text in chapter 7 suggests so. Section 7 includes: secg-scheme OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) certicom(132) schemes(1) } which is followed by 3 OIDs assigned in that arc. Section 7 also includes: smime-alg OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) } which is followed by three TBD OID values that need to be assigned by = IANA once the document is approved. > Maybe it would be a bit clearer if the text stated explicitly which of > the OIDs in the chapter are NEW, and which ones already exist and are > provided for reference/context. Once IANA makes the three assignments, all of the OID values will appear = in the RFC. Russ --Apple-Mail=_EA2DDDBE-2388-4EAD-832E-E31DE0D1D28D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 23, 2017, at 5:29 AM, Stefan Winter <stefan.winter@restena.lu> wrote:

Reviewer: Stefan Winter
Review result: Has = Nits

Nits:

* = 2.1 starts with "...  based on a one-way hash function described = in
ANS X9.63 [X963]." s/ANS/ANSI/

The = American National Standards Institue (ANSI) is an organization. =  See https://www.ansi.org/.

American National Standards (ASN) are documents. =  In this case, ANS X9.63 is being referenced.

I will expand ANS to American National Standard to = avoid future confusion.


* Chapter 7 = defines six OIDs (secg-scheme 11 1...3 and smime-alg
TBD1...3) and also includes the base OIDs under which these = new OIDs
are attached (secg-scheme and smime-alg). Those = two are not defined in
this document, but the text in = chapter 7 suggests so.

Section 7 includes:

      secg-scheme OBJECT = IDENTIFIER ::=3D {
        iso(1) = identified-organization(3) certicom(132) schemes(1) }

which is followed by 3 OIDs assigned in that = arc.


Section= 7 also includes:

    =   smime-alg OBJECT IDENTIFIER ::=3D {
    =      iso(1) member-body(2) us(840) rsadsi(113549) = pkcs(1)
         pkcs-9(9) smime(16) = alg(3) }

which is followed by three = TBD OID values that need to be assigned by IANA once the document is = approved.

Maybe it would be a bit = clearer if the text stated explicitly which of
the OIDs in = the chapter are NEW, and which ones already exist and are
provided for reference/context.

Once IANA = makes the three assignments, all of the OID values will appear in the = RFC.

Russ

= --Apple-Mail=_EA2DDDBE-2388-4EAD-832E-E31DE0D1D28D-- From nobody Fri May 26 18:33: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 D48C9129B74; Fri, 26 May 2017 18:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W19sB5B902U8; Fri, 26 May 2017 18:33:46 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 DE94312940F; Fri, 26 May 2017 18:33:42 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id a5so13490855lfh.2; Fri, 26 May 2017 18:33: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=i1nmYy1+l1o03GPXGopcgyBKuHr8MADo1MiSwXgLlFw=; b=hfjAu/iFj2wr2IK6m1b1qZmZn1mesZnCYU+Zk5SyH8MuYUT0+ac1LAldzXlw+u6rn6 qo3P+NprxlfbjyAdyDxcK9ij4lNVej36nfWVTfycZA5wUeAz8q/6wjsHA5eTc/R0hDme 0w+jE3YkBV0ShFHfQ7JJ5Nf7i+d3RQrmvt9f1lzCpuEN4hjQYYOylwP2N4HMBOt3Jc95 CEg2OUO2Df+o6EdueEPe4s9TmHHT6waoGyZCRSwh9I5r1EpDc8WUPlfmX7berZFCOC87 3DPjlOW4i2AUwb+12hDOoh0OrYjuDc+t94nKxyGEE/On9vBtjX4J/2l0iC/0OGz/YZXB nDCQ== 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=i1nmYy1+l1o03GPXGopcgyBKuHr8MADo1MiSwXgLlFw=; b=SKx1XCuS1qbINKDNGhoVjvGEmhhWgvufRRzV1nrMXVsiwZc4YK/zFHL2V8if0Avd17 6rrfyNcwz9zP1oz53VDeNChjWJTZF71kVa2aPQ2kJddfX+mdTzvCuUbyu/T6wVTsF9LO xxiedopmDyf3E4g6UuajCXIKlfSq5tlmq99aj/gdUk3XA4Rj0N8ErzGl0LvH6P8DxwBc ugCb08LUmqKYM0qdh63BgYY0GpbQtFlNjrJ2Kni5S9zdnKCDLulX0vPemBx/lBLJqQnl FYv3BQnj326rm0IymW7rhUb3usja4nnMsEtDdxSd7SLKU/cO4MDEGdAqU7cJkIYLwCky nEHA== X-Gm-Message-State: AODbwcCXspQo5dxcF1RFcQMB/0OXF7gOpbs1+JidhP60OSeUrl+Q09P5 GvPA4TzlSN5YiN2Iwo/eidt6o76s9g== X-Received: by 10.25.104.5 with SMTP id d5mr1484330lfc.147.1495848821228; Fri, 26 May 2017 18:33:41 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 26 May 2017 18:33:40 -0700 (PDT) In-Reply-To: <149570983670.8681.5001417855088402577@ietfa.amsl.com> References: <149570983670.8681.5001417855088402577@ietfa.amsl.com> From: Daniel Migault Date: Fri, 26 May 2017 21:33:40 -0400 X-Google-Sender-Auth: BsW1gIuTArfSwfSzWZ7rcgrTqZc Message-ID: To: Roni Even Cc: "gen-art >> General area reviewing team" , draft-ietf-curdle-cms-ecdh-new-curves.all@ietf.org, curdle , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="f403045e589ca08b9f05507771bf" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 01:33:48 -0000 --f403045e589ca08b9f05507771bf Content-Type: text/plain; charset="UTF-8" Thank you Roni for the review. Yours, Daniel On Thu, May 25, 2017 at 6:57 AM, Roni Even wrote: > Reviewer: Roni Even > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-curdle-cms-ecdh-new-curves-?? > Reviewer: Roni Even > Review Date: 2017-05-25 > IETF LC End Date: 2017-05-28 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > Nits/editorial comments: > > In general it was easy to read and follow. Maybe it will be good to > repeat in section 3.2 the definition of KeyAgreeRecipientInfo . This > is done is section 2 for ECC-CMS-SharedInfo but it is not crucial. > > 1. There is no ToC > 2. In section 2.2 fourth paragraph "is used two places" - "in two .." > > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045e589ca08b9f05507771bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Roni for the review.
Yours, <= br>
Daniel

On Thu, May 25, 2017 at 6:57 AM, Roni Even <ron.even.tlv@gmai= l.com> wrote:
Reviewer: Ron= i Even
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-curdle-cms-ecdh-new-curves-??
Reviewer: Roni Even
Review Date: 2017-05-25
IETF LC End Date: 2017-05-28
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as a standard track RFC

Major issues:

Minor issues:

Nits/editorial comments:

In general it was easy to read and follow.=C2=A0 Maybe it will be good to repeat in section 3.2 the definition of KeyAgreeRecipientInfo . This
is done is section 2 for ECC-CMS-SharedInfo but it is not crucial.

1. There is no ToC
2. In section 2.2 fourth paragraph "is used two places" - "i= n two .."





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

--f403045e589ca08b9f05507771bf-- From nobody Sat May 27 08:25: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 931B0127333 for ; Sat, 27 May 2017 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W__ydEGuq2-G for ; Sat, 27 May 2017 08:24:59 -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 738B31250B8 for ; Sat, 27 May 2017 08:24:59 -0700 (PDT) X-AuditID: 1209190e-67dff700000023cd-9f-59299a4702c2 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.E2.09165.74A99295; Sat, 27 May 2017 11:24:56 -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 v4RFOsQa029444; Sat, 27 May 2017 11:24:55 -0400 Received: from [18.101.8.78] (vpn-18-101-8-78.mit.edu [18.101.8.78]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4RFOp2d019402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 27 May 2017 11:24:53 -0400 To: Benjamin Kaduk References: <20170526044907.GC39245@kduck.kaduk.org> Cc: curdle@ietf.org From: Greg Hudson Message-ID: Date: Sat, 27 May 2017 11:24:51 -0400 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: <20170526044907.GC39245@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqresxSzPS4OxCcYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/KJY0wF71kr9m5eydLAeIWli5GTQ0LAROLNo/vsXYxcHEIC i5kkWs5fZYFwNjJKPDv3mBnCOcQkceVhFyNIi7CAr8S2d7fZQWwRASWJxWdb2LoYOYCKYiR2 nOMDCTMLCEv8+9zKBGKzCShLrN+/FWwbr4CVxN/tZ8DGsAioStyZfRUsLioQIfGwcxc7RI2g xMmZT8DinAKmEucuLmOBmKknseP6L1YIW15i+9s5zBMYBWYhaZmFpGwWkrIFjMyrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgoNSkm8H46QG70OMAhyMSjy8M7o1IoVYE8uK K3MPMUpyMCmJ8k5fpx4pxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3TplmpBBvSmJlVWpRPkxK moNFSZxXXKMxQkggPbEkNTs1tSC1CCYrw8GhJMHLMxOoUbAoNT21Ii0zpwQhzcTBCTKcB2i4 L0gNb3FBYm5xZjpE/hSjLkfThy1fmIRY8vLzUqXEec/NACoSACnKKM2DmwNOJqkcfq8YxYHe EubtBBnFA0xEcJNeAS1hAllyTh1kSUkiQkqqgVHxSnRYv8yjxX/aNXz/FX3fFt0tca1i7zFV L/f5h+aGJyhVvPptsMsw4pb42Utsf8s+arhNPHd19skvnb/MhddGPk3Kdlgd2PFc6sKzt4uu TT3xJnNjlKOJVLnpuTmbPmr9OshiuCQwUkfqdtWVPJnbbY3+BSnz/VxXX5PXZT2Umv4zTp3J cKESS3FGoqEWc1FxIgBlsKK7AQMAAA== Archived-At: Subject: Re: [Curdle] Review of draft-kaduk-kitten-des-des-des-die-die-die-01 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, 27 May 2017 15:25:00 -0000 On 05/26/2017 12:49 AM, Benjamin Kaduk wrote: >> Section 5.2, "It is also best practice when [...], to" should have a >> comma before "when". Also, "it is also best practice" doesn't seem >> right. > > Sure, these commas need to come in pairs. Is dropping to just "it > is best practice" enough of an improvement to make you happy? > (There's not really a preceeding instance that would make the "also" > useful.) How to use "best practice" grammatically seems to be a matter of some debate; for me personally, it looks wrong without an article. "It is the best practice when [...]" would look okay to me. As I noted before, this is a non-blocking objection, and you should feel free to let the RFC editor worry about this stuff. From nobody Tue May 30 04:31: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 12327129BD8 for ; Tue, 30 May 2017 04:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 o_gQ5Kw_L-Wh for ; Tue, 30 May 2017 04:31:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07121120454 for ; Tue, 30 May 2017 04:31:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9468C81235; Tue, 30 May 2017 11:31:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9468C81235 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9468C81235 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE62318C5A; Tue, 30 May 2017 11:31:25 +0000 (UTC) Message-ID: <1496143884.7897.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley , curdle Cc: Eric Rescorla Date: Tue, 30 May 2017 13:31:24 +0200 In-Reply-To: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> References: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 30 May 2017 11:31:26 +0000 (UTC) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 11:31:28 -0000 On Mon, 2017-05-08 at 13:32 -0400, Russ Housley wrote: > > TECHNICAL > > S 3.1 and 3.2. > > - Is there some reason to not prescribe exactly one form here? > >   I.e., require id-sha512 (etc.) or require it not be there? > > > > - Also, TLS has converged on talking about an "identity" hash > >   for the PureEd forms. Was this discussed and rejected? > > 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.  Eric is suggesting that the “identity” hash could be > used with Ed25519 and Ed448 when there are no attributes to > hash.  Using ED25519 as an example, we get: > >    IF (signed attributes are absent) >    THEN > signedData.digestAlgorithms includes id-hashIdentity >         signedData.signerInfo.digestAlgorithm = id-hashIdentity >         signedData.signerInfo.signature = Ed25519(content) >    ELSE > signedData.digestAlgorithms includes id-sha512 >         signedData.signerInfo.digestAlgorithm = id-sha512 > signedData.signerInfo.signedAttrs includes message-digest = > SHA512(content) >         signedData.signerInfo.signature = > Ed25519(DER(signedData.signerInfo.signedAttrs)) > > Do others think the use of an algorithm identifier for the “identity” > hash is better?  The current document include id-sha512 as a warning > that Ed25519 uses that hash algorithm internally. I miss the benefit of that change. Given that the flag 'signed attributes are absent' is sufficient to determine the action to be done, adding the identity hash identifier, can only create confusion. The confusion can be because now we have multiple additional states which provide no additional information. E.g. the following are simply invalid: 'signed attributes are absent' and digestAlgorithm != id-hashIdentity 'signed attributes are present' and digestAlgorithm = id-hashIdentity I prefer the original approach due to its simplicity. regards, Nikos From nobody Tue May 30 04:31: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 9D488129BEE for ; Tue, 30 May 2017 04:31:35 -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 bsAIIyvARONn for ; Tue, 30 May 2017 04:31:34 -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 2B7D2129BE0 for ; Tue, 30 May 2017 04:31:33 -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 C75698124D; Tue, 30 May 2017 11:31:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C75698124D Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C75698124D Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 203135C8A6; Tue, 30 May 2017 11:31:31 +0000 (UTC) Message-ID: <1496143890.7897.6.camel@redhat.com> From: Nikos Mavrogiannopoulos To: housley@vigilsec.com Cc: curdle@ietf.org Date: Tue, 30 May 2017 13:31:30 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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.25]); Tue, 30 May 2017 11:31:32 +0000 (UTC) Archived-At: Subject: [Curdle] test vectors for draft-ietf-curdle-cms-eddsa-signatures-05 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 11:31:36 -0000 Hi, The latest draft-ietf-curdle-cms-eddsa-signatures-05 does not contain any test structures with eddsa signed data. While the text seems sufficiently precise to implement that, I think it is a good practice to include test vectors in an appendix similarly to draft-ietf-curdle- pkix-04. regards, Nikos From nobody Tue May 30 08:38: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 29C4B129584 for ; Tue, 30 May 2017 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-RghFy7Arwo for ; Tue, 30 May 2017 08:38:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFEE129576 for ; Tue, 30 May 2017 08:38:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 02551300561 for ; Tue, 30 May 2017 11:38:10 -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 UOfr4vTLK9q6 for ; Tue, 30 May 2017 11:38:08 -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 D624C3000E0; Tue, 30 May 2017 11:38:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1496143884.7897.5.camel@redhat.com> Date: Tue, 30 May 2017 11:38:13 -0400 Cc: Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <43EFAB9A-6AEE-4A5D-BCD7-DB5732718D1B@vigilsec.com> References: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com> <1496143884.7897.5.camel@redhat.com> To: curdle X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:38:12 -0000 My assessment is that people are fine with the approach in the document. Russ > On May 30, 2017, at 7:31 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, 2017-05-08 at 13:32 -0400, Russ Housley wrote: >>> TECHNICAL >>> S 3.1 and 3.2. >>> - Is there some reason to not prescribe exactly one form here? >>> I.e., require id-sha512 (etc.) or require it not be there? >>>=20 >>> - Also, TLS has converged on talking about an "identity" hash >>> for the PureEd forms. Was this discussed and rejected? >>=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. Eric is suggesting that the =E2=80=9Cidentity=E2=80=9D = hash could be >> used with Ed25519 and Ed448 when there are no attributes to >> hash. Using ED25519 as an example, we get: >>=20 >> IF (signed attributes are absent) >> THEN >> signedData.digestAlgorithms includes id-hashIdentity >> signedData.signerInfo.digestAlgorithm =3D id-hashIdentity >> signedData.signerInfo.signature =3D Ed25519(content) >> ELSE >> signedData.digestAlgorithms includes id-sha512 >> signedData.signerInfo.digestAlgorithm =3D id-sha512 >> signedData.signerInfo.signedAttrs includes message-digest =3D >> SHA512(content) >> signedData.signerInfo.signature =3D >> Ed25519(DER(signedData.signerInfo.signedAttrs)) >>=20 >> Do others think the use of an algorithm identifier for the = =E2=80=9Cidentity=E2=80=9D >> hash is better? The current document include id-sha512 as a warning >> that Ed25519 uses that hash algorithm internally. >=20 > I miss the benefit of that change. Given that the flag 'signed > attributes are absent' is sufficient to determine the action to be > done, adding the identity hash identifier, can only create confusion. > The confusion can be because now we have multiple additional states > which provide no additional information. >=20 > E.g. the following are simply invalid: > 'signed attributes are absent' and digestAlgorithm !=3D = id-hashIdentity > 'signed attributes are present' and digestAlgorithm =3D = id-hashIdentity >=20 > I prefer the original approach due to its simplicity. >=20 > regards, > Nikos >=20 From nobody Tue May 30 08:54:03 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0D4129BA3; Tue, 30 May 2017 08:53:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149615963407.14861.3880646941383961758@ietfa.amsl.com> Date: Tue, 30 May 2017 08:53:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-08.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:53:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-08.txt Pages : 10 Date : 2017-05-30 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 30 08:55:21 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 E473D129AA3; Tue, 30 May 2017 08:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149615971290.14853.11098516798796780052@ietfa.amsl.com> Date: Tue, 30 May 2017 08:55:12 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-08.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:55: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 : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-08.txt Pages : 8 Date : 2017-05-30 Abstract: This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 30 09:33: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 EF1FD129A97 for ; Tue, 30 May 2017 09:33:53 -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 jMcQ8h48gSct for ; Tue, 30 May 2017 09:33:52 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAA31200E5 for ; Tue, 30 May 2017 09:33:51 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l14so42528813ywk.1 for ; Tue, 30 May 2017 09:33:51 -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=Ef3f00stCf2kdtbON5NYBk/UInfK7DziVhlo4g32qPU=; b=Zjmfg+NBhApE7SnfoJexGcCuvOIeSaleLBhw7V9HMCz8wrANwcsfMYNk+26w3GRtRu yMrMYqlO1gm5ZFOR8d0HdZio5+0gaaXYtgANshVcTcX1Hx9+7RJ9TozIxyUGLDYp4/Es HggziMbI+MS6mmonAKiyWNvxh1wDzSpl+uJptVGLegwvkGc4uB319HC+md+jy7M19J6L zW5FwBxp9jsiPQeHNW7SSquZ8IRrcwZqBykCzW5yTfTO5tbXtCdq/5Eo9n1yNh+R0sAo s8kBqXyOHKEmAw3qSHmHq3azBhHp0bYt1E5IOG88yGG35SoUM7+uk7Z57lajDGG/nNXp v1/A== 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=Ef3f00stCf2kdtbON5NYBk/UInfK7DziVhlo4g32qPU=; b=Sviae7hcdAu4jtLFV+xCt4zOPOhkeXif4cu9haRCplGZDjVgJwegI6e/9Qvwc6cwLk HkXB+CY1K1sslXO+vsrNCi22rQGvJyWEEO+8G+S2ok259XpOI2AAtxjImMBxeFh1m6IY 3RWyg2E9+76+MvfGlwtfdBjLXSZTo+7mUreDtJCpFkIDS1mAdmA9c+gB47Wglzr0h2qP Q+TV9nMpDOOX1UcGNg7iGc44qk3OCr9lR+Vgsp0+wru5jksi9RVdq4mNnEGkW8RdC5BW 0kJBVm0njkeLDvSmeU02WQfkq8RdYXfT4UxbSkWMEXJMzCG3RV1MTGdJDWTg20+sc7X3 CgIg== X-Gm-Message-State: AODbwcCzma6wVP1KzRX857dozUaS11T8SbVxj1j6VF6wxAT4esT8snJe fVjPUAyyOHngusPjkRUZKJrgvNb99A== X-Received: by 10.129.40.144 with SMTP id o138mr16639431ywo.154.1496162031231; Tue, 30 May 2017 09:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.21.65 with HTTP; Tue, 30 May 2017 09:33:50 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Tue, 30 May 2017 10:33:50 -0600 Message-ID: To: Daniel Migault Cc: curdle Content-Type: multipart/alternative; boundary="001a11409ede65e8760550c05e91" Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-rsa-sha2 shepherd write-up/nits 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, 30 May 2017 16:33:54 -0000 --001a11409ede65e8760550c05e91 Content-Type: text/plain; charset="UTF-8" Hello Daniel, thank you for your help! I have updated the two drafts accordingly. I have reviewed the write-ups, and can think of no comments. denis On Fri, May 26, 2017 at 9:11 AM, Daniel Migault wrote: > Hi, > > The draft draft-ietf-curdle-rsa-sha2 is almost ready to be sent to IESG. I > have found some minor nits to be addressed to complete the shepherd write > up. > > The shepherd write up is available [here]. Feel free to comment in the > next few days. > > nits: > Please mention in the section "1. Overview and Rationale": > > This memo updates RFC 4252 and RFC 4253. > > section 3.2 > > As all terms user_name, service_name... are not defined in the document, I > suggest to replace: > > OLD: > For example, an SSH "publickey" authentication request using an > "rsa-sha2-512" signature would be properly encoded as follows: > > NEW: > For example, as defined [RFC4252] and [RFC4253], an SSH "publickey" > authentication request using an "rsa-sha2-512" signature would be properly > encoded as follows: > > > Yours, > Daniel > > [here] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa- > sha2/shepherdwriteup/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11409ede65e8760550c05e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Daniel,

thank you for your help!<= /div>

I have updated the two drafts accordingly.

I have reviewed the write-ups, and can think of no commen= ts.

denis


On Fri, May 26, 2017 at 9:11 AM= , Daniel Migault <daniel.migault@ericsson.com> wro= te:
Hi,
The draft draft-ietf-curdle-rsa-sha2 is almost ready to be sent to = IESG. I have found some minor nits to be addressed to complete the shepherd= write up.

The shepherd write up is available [here]. Feel free to c= omment in the next few days.

nits:
Please mentio= n in the section "1.=C2=A0 Overview and Rationale":

This = memo updates RFC 4252 and RFC 4253.=C2=A0

section 3.2

As al= l terms user_name, service_name... are not defined in the document, I sugge= st to replace:

OLD:
For example, an SSH "publickey" aut= hentication request using an
"rsa-sha2-512" signature would be= properly encoded as follows:

NEW:
For example, as defined [RFC42= 52] and [RFC4253], an SSH "publickey" authentication request usin= g an "rsa-sha2-512" signature would be properly encoded as follow= s:

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

[here] ht= tps://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/shepher= dwriteup/=C2=A0

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

--001a11409ede65e8760550c05e91-- From nobody Tue May 30 12:48: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 A355B1250B8 for ; Tue, 30 May 2017 12:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AUt6GvhBx5q for ; Tue, 30 May 2017 12:48:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB4C1292FD for ; Tue, 30 May 2017 12:48:27 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 99so54748540lfu.1 for ; Tue, 30 May 2017 12:48:27 -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=i73qHwfn5y1WRefWRtdHoD+80XLT8PeR8Y3rOEdG2TQ=; b=tjXzg+jBkkIoyVA50neDVEuXVv+2zNHV6icQFHUXYSAnv1hRFtqpa4gpF/0DcWYHP2 S/rA2hzKuEcdcXOtecSZKtco6s123rt0OKTRqFyCo88ZGsst5USEMiRLOt2YxHXh1mrX NVn+EM3EM1bPZNb2gsW706W0kxdzHL01XzB9MgDFeDYj6WGbBZCA5ijUwDO9bW42HfUi W9/eZqvWdz8H5XWmM29STzehKXwAg073mAAdgTuYHXq68JGGmcmvQWMxVaYnRzVTQD29 HBOWYmEXnmn1ahLJWwT83BAgcgyLKznhokP86QDOKmGSNi28yMsk09Yxunobc2Op6zyF e5BQ== 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=i73qHwfn5y1WRefWRtdHoD+80XLT8PeR8Y3rOEdG2TQ=; b=ePlHvzXFbr+66im0Bdl1l0NdJZAvcBsYgUAZMyj7Dr9M4TzmZc1KnTYBdpu0oCIOam 6FNYGVvze5AelUuiZcDaCf0FWdCzo30h5CaUVRrTV0tENPf6NQeqp0XKNq20YbqFKEC8 eyI4eeas0BGYH/GqU+FR+8vEDPsiUK/Rv3N8WwqY0Kbivn9d1Whx7wBhWjI1pNrFXeod M9UMZUo8BdK0bw1N5QpPcWC6DfiQYVUBX8zKHGMExpZHw8uFRHBNPHvBPGrRw4O+HFjD L/ODvgm0cQPZycQ12S0IJUEzU+kaL/JW85Ml3bYInjAkK5R0GGVB33GkWYuE2a+t/1Kd gH3Q== X-Gm-Message-State: AODbwcB439r7P0EGQ/BX/7Mt6gH/bPpWA25KS8n7ckzkJMbr9n0VTtVC /baQiqrmsOw5d0GuKXX9C4MVRl+lUA== X-Received: by 10.25.193.145 with SMTP id r139mr6834326lff.111.1496173705577; Tue, 30 May 2017 12:48:25 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Tue, 30 May 2017 12:48:24 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 30 May 2017 15:48:24 -0400 X-Google-Sender-Auth: gLeon_pGR-vnu-ZDtOqqTP8HPCU Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c1a08783e4da50550c31678" Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-rsa-sha2 shepherd write-up/nits 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, 30 May 2017 19:48:30 -0000 --94eb2c1a08783e4da50550c31678 Content-Type: text/plain; charset="UTF-8" Hi Denis, Thank you very much Denis, for the update. I will have a look at them tomorrow and hopefully send them to the IESG at the same time. If anyone has something to say, please raise your concern as soon as possible. Yours, Daniel On Tue, May 30, 2017 at 12:33 PM, denis bider wrote: > Hello Daniel, > > thank you for your help! > > I have updated the two drafts accordingly. > > I have reviewed the write-ups, and can think of no comments. > > denis > > > On Fri, May 26, 2017 at 9:11 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> The draft draft-ietf-curdle-rsa-sha2 is almost ready to be sent to IESG. >> I have found some minor nits to be addressed to complete the shepherd write >> up. >> >> The shepherd write up is available [here]. Feel free to comment in the >> next few days. >> >> nits: >> Please mention in the section "1. Overview and Rationale": >> >> This memo updates RFC 4252 and RFC 4253. >> >> section 3.2 >> >> As all terms user_name, service_name... are not defined in the document, >> I suggest to replace: >> >> OLD: >> For example, an SSH "publickey" authentication request using an >> "rsa-sha2-512" signature would be properly encoded as follows: >> >> NEW: >> For example, as defined [RFC4252] and [RFC4253], an SSH "publickey" >> authentication request using an "rsa-sha2-512" signature would be properly >> encoded as follows: >> >> >> Yours, >> Daniel >> >> [here] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ >> shepherdwriteup/ >> >> _______________________________________________ >> 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 > > --94eb2c1a08783e4da50550c31678 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,

Thank you very much Denis, for= the update. I will have a look at them tomorrow and hopefully send them to= the IESG at the same time. If anyone has something to say, please raise yo= ur concern as soon as possible.

Yours,
Daniel

On Tue, May 3= 0, 2017 at 12:33 PM, denis bider <denisbider.ietf@gmail.com>= ; wrote:
Hello Da= niel,

thank you for your help!

= I have updated the two drafts accordingly.

I have = reviewed the write-ups, and can think of no comments.

<= div>denis


On Fri, May 26, 2017 at 9:11 AM, = Daniel Migault <daniel.migault@ericsson.com> wrote= :
Hi,

The draft draft-ietf-curdle-rsa-sh= a2 is almost ready to be sent to IESG. I have found some minor nits to be a= ddressed to complete the shepherd write up.

The shepherd write up is= available [here]. Feel free to comment in the next few days.

nits:
Please mention in the section "1.=C2=A0 Overview a= nd Rationale":

This memo updates RFC 4252 and RFC 4253.=C2=A0 =

section 3.2

As all terms user_name, service_name... are not= defined in the document, I suggest to replace:

OLD:
For example,= an SSH "publickey" authentication request using an
"rsa-= sha2-512" signature would be properly encoded as follows:

NEW:<= br>For example, as defined [RFC4252] and [RFC4253], an SSH "publickey&= quot; authentication request using an "rsa-sha2-512" signature wo= uld be properly encoded as follows:

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

[here] https://datatracker.ietf.org/doc/draft-i= etf-curdle-rsa-sha2/shepherdwriteup/=C2=A0

_______________________________________________
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

--94eb2c1a08783e4da50550c31678-- From nobody Tue May 30 21:22:42 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 AEDA6129B46; Tue, 30 May 2017 21:22:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149620456167.19836.5659815165303681119@ietfa.amsl.com> Date: Tue, 30 May 2017 21:22:41 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-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: Wed, 31 May 2017 04:22:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-01.txt Pages : 9 Date : 2017-05-30 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-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 Tue May 30 21:26: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 CD64B126C0F for ; Tue, 30 May 2017 21:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUImiIDQ3bfb for ; Tue, 30 May 2017 21:26:13 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 B8E451287A7 for ; Tue, 30 May 2017 21:26:13 -0700 (PDT) X-AuditID: 12074423-a8bff70000007695-c9-592e45e2bb70 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 92.C3.30357.2E54E295; Wed, 31 May 2017 00:26:11 -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 v4V4Q91m032607 for ; Wed, 31 May 2017 00:26:10 -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 v4V4Q59K023970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 May 2017 00:26:08 -0400 Date: Tue, 30 May 2017 23:26:05 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170531042605.GM39245@kduck.kaduk.org> References: <149620456167.19836.5659815165303681119@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149620456167.19836.5659815165303681119@ietfa.amsl.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixCmqrfvYVS/SYMNNC4utC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48KHU0wFfUIVB5+eZ29gXM7XxcjJISFgIvFtxk/GLkYuDiGB xUwSKz/0M0E4xxklzmxvg8q8ZpJYfvkuI0gLi4CqROuX+2A2m4CKREP3ZeYuRg4OEQFhiZ4F kiBhYYEQicnHHrGB2LxAG96cOsICYgsJOEtc7jnBChEXlDg58wlYnFlAS+LGv5dMIGOYBaQl lv/jAAlzCrhI9M3+A1YuKqAs8ffwPZYJjPyzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd 4uTEvLzUIl0zvdzMEr3UlNJNjKDAY3dR3sH4ss/7EKMAB6MSD69BmW6kEGtiWXFl7iFGSQ4m JVHeChu9SCG+pPyUyozE4oz4otKc1OJDjBIczEoivBP1gXK8KYmVValF+TApaQ4WJXFecY3G CCGB9MSS1OzU1ILUIpisDAeHkgRvlgtQo2BRanpqRVpmTglCmomDE2Q4D9DwVSA1vMUFibnF mekQ+VOMilLivOHOQAkBkERGaR5cLygxSGTvr3nFKA70ijDvIpB2HmBSget+BTSYCWjwrh3a IINLEhFSUg2MCjwPRBbt6tmTwvTua/kDW6s3f8/GvnRNVTm6a07vt9PT2xj4rZ4nNgZylH4r YgiaejEoYKZ9V3ryjZdOJTOiVu2P6+hS6FoVU1i3Q9D9hP696S8e5hzcynHHyDKCm81DdmKk xKdD277n/rq550Pxw9Mavsr/XTL7vy67fW2/+vMDbLofsxmVlFiKMxINtZiLihMBybmNS+cC AAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 04:26:16 -0000 The main change here is to target BCP instead of Informational. I think I addressed the other concrete items that came up in the WGLC review; please let me know if I missed anything. At this point, I think the only outstanding questions are whether to remain as targetting BCP vs. standards track, and semi-relatedly whether to leave the prohibition against using these enctypes as SHOULD NOT (to match RFC 6649) or go to the stronger MUST NOT. -Ben On Tue, May 30, 2017 at 09:22:41PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-01.txt > Pages : 9 > Date : 2017-05-30 > > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-01 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed May 31 05:21: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 039281242F7 for ; Wed, 31 May 2017 05:21: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 5LIg5CG70PCq for ; Wed, 31 May 2017 05:21:37 -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 063BD120454 for ; Wed, 31 May 2017 05:21:36 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4VCHNHp009449; Wed, 31 May 2017 13:21:35 +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=lJjWpssVo4eOnaS0ucOfyziOGaq4nOYUhwQ6szvLi9A=; b=ai+vEMPgT6Gwb0nkg3zLn+/HMYM18VVJwD1ck41J3OVPW1uQm7TtNp/tn/wvoWtNmAWV yA598aiqU84blSy8rgr5NIKS9cVgKJS4R+Vtvk/HcIOuQk9tFe2C7ASYIxQbQCvDsBN0 8MdhOatjNQrS7j/UO5mK6ixB8BsrnY3cpabvKrC6+H+ocN43QxH132HWo+uzmJGi5SVn BlSNosoapvVjDuPj15Fj2OVh6AIAiOREgHub0eqGzJMjW2+TFSqWWdjdekG7jeG6sXs1 oahBSrUAZtissoxN1WkwrZl0T9OFpKa+X4e9rGV4oX77wm2RKAfFvUa5c67j9rjl3LXl uA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2arswjj2ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 May 2017 13:21:34 +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 v4VCLWKx029784; Wed, 31 May 2017 08:21:34 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aq4sucyqy-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 May 2017 08:21:33 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 31 May 2017 08:21:32 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 31 May 2017 08:21:32 -0400 From: "Salz, Rich" To: Benjamin Kaduk , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt Thread-Index: AQHS2cWOSvkSLhx0SkiwBxxywC8JaqIOG4yAgABBKIA= Date: Wed, 31 May 2017 12:21:31 +0000 Message-ID: References: <149620456167.19836.5659815165303681119@ietfa.amsl.com> <20170531042605.GM39245@kduck.kaduk.org> In-Reply-To: <20170531042605.GM39245@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.130] 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-05-31_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310227 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-31_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310226 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:21:38 -0000 > At this point, I think the only outstanding questions are whether to rema= in as > targetting BCP vs. standards track, and semi-relatedly whether to leave t= he > prohibition against using these enctypes as SHOULD NOT (to match RFC 6649= ) > or go to the stronger MUST NOT. 6649 is BCP, 7465 is standards-track. I lean towards BCP and SHOULD. From nobody Wed May 31 05:45: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 A3A2E12946D for ; Wed, 31 May 2017 05:45:10 -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 BSPZZwPAfiLJ for ; Wed, 31 May 2017 05:45:09 -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 076B8128D3E for ; Wed, 31 May 2017 05:45:08 -0700 (PDT) X-AuditID: c6180641-731a89a0000037f2-8d-592e74751d04 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id D6.7F.14322.5747E295; Wed, 31 May 2017 09:44:54 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0339.000; Wed, 31 May 2017 08:45:07 -0400 From: Daniel Migault To: "Salz, Rich" , Benjamin Kaduk , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt Thread-Index: AQHS2cWQfxHX0veudkiTUlTjl0zZAKIOG4yAgACE1YD//8HbIA== Date: Wed, 31 May 2017 12:45:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C714F8@eusaamb107.ericsson.se> References: <149620456167.19836.5659815165303681119@ietfa.amsl.com> <20170531042605.GM39245@kduck.kaduk.org> 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.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPoG5ZiV6kQeMadoutC2cxWyzfOJPJ 4v+WThYHZo/JRxYweyxZ8pPJo+nMUeYA5igum5TUnMyy1CJ9uwSujLdLTrEVHOeoOPZ1M1sD Yz97FyMnh4SAicSupl9ANheHkMBRRol5K3rYIJzljBJ9n3eyglSxCRhJtB2C6BARyJLYsWAy mC0sECLx6/AaNoh4qMSnvl0sELaTRMuDSYwgNouAqkTPqdVgNq+Ar8T/SxuhFmxnlDj6+g/Y Ak6BYIlv+w6ADWUUEJP4fmoNE4jNLCAucevJfCaIUwUkluw5zwxhi0q8fPyPFcJWkvj4ez47 RL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGkVlIxs5C0jILScssJC0LGFlWMXKUFhfk5KYb GW5iBEbDMQk2xx2Me3s9DzEKcDAq8fBuj9WLFGJNLCuuzD3EKMHBrCTCa7MVKMSbklhZlVqU H19UmpNafIhRmoNFSZz3XfmFCCGB9MSS1OzU1ILUIpgsEwenVAOj37IfW5z3e+3Q/TTN6M78 cqVtZWV3OLg1JExF0+2PHXs0mVP6parcv9OGmtPueZ3Jjzwx8/XlmE1Hd8xL77L99yHqtiTD Ko9EOfNfTKKL0v5zmFiybG2rOnM8ScgmsSPds9nV+UJbaKj9xFsV53ZM4GVon3/kyIkdP0Od Hjya+ffh6qVBvSWblFiKMxINtZiLihMBWIPBnIICAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:45:11 -0000 Thank you Benjamin for the update. If MUST NOT cannot be enforced, so reali= stically SHOULD NOT might be preferred. Or something like REALLY SHOULD NOT= from RFC6919 might also be considered. I am fine either way BCP or standard track. I would like the WG to express = its preferences.=20 Yours,=20 Daniel=20 -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, May 31, 2017 8:22 AM To: Benjamin Kaduk ; curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die= -01.txt > At this point, I think the only outstanding questions are whether to=20 > remain as targetting BCP vs. standards track, and semi-relatedly=20 > whether to leave the prohibition against using these enctypes as=20 > SHOULD NOT (to match RFC 6649) or go to the stronger MUST NOT. 6649 is BCP, 7465 is standards-track. I lean towards BCP and SHOULD. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed May 31 14:29: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 F0FA0124234 for ; Wed, 31 May 2017 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBrKXwqG0syK for ; Wed, 31 May 2017 14:29:17 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.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 955CC129C30 for ; Wed, 31 May 2017 14:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xUsxVVSkJ+QiwcisSEt8+X3IzIdpDozh0j983/GjwgA=; b=iysXfcAOP4N68MBBjV2oMiYgo1QJ1upC8C7nS90QeOB1nZsye1Y69pHm6ejVrK4h6PPwU3sCkw5IdRuBvrrO4UwWMAKtmCCxOwz0iAZTM/ve9hiWIEnV/9NP5KjFnWYCBaTK0/YtKOiHOPcwkw3ScF8XGatskzMIiyJhL74Fgok= Received: from BLUPR0301MB1554.namprd03.prod.outlook.com (10.162.214.12) by BLUPR0301MB1556.namprd03.prod.outlook.com (10.162.214.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Wed, 31 May 2017 21:29:14 +0000 Received: from BLUPR0301MB1554.namprd03.prod.outlook.com ([10.162.214.12]) by BLUPR0301MB1554.namprd03.prod.outlook.com ([10.162.214.12]) with mapi id 15.01.1124.020; Wed, 31 May 2017 21:29:14 +0000 From: Michiko Short To: "Salz, Rich" , Benjamin Kaduk , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt Thread-Index: AQHS2kAtOe6uPk6e0Uu/RGPo21ARA6IO9JUA Date: Wed, 31 May 2017 21:29:14 +0000 Message-ID: References: <149620456167.19836.5659815165303681119@ietfa.amsl.com> <20170531042605.GM39245@kduck.kaduk.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::681] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1556; 7:7u3KcMo1PwVs3bsiavTnUUxoNSn70dT1hnI1W/nq65Qd9CTfeP7YdZFPKl4pI3fFMrBpWDB+9imWSYk0GhmP8CPT5TMzZZ2c5xzZu8MJC/aWnlmw/Dz/dFoq1v9GQWxNC2528sHJKXg7DoboHiKB6cft289dB/D34lHf/AJUnqQ9jt+l/FSy116Wc3JjhhsN9+kEYSINiafTQQp5W0qaD8IwClM5YBOE1vXG81691ATtgeMAWoegZGds/naZ83wNsSbt830ZkFV1ixI/U8vFBt0qEnfNuthkTjIBgAXIkFwGq67tTiECneke5+tzXcONm37jhKV/VsqdyC5Kyn7XyU9xvbvasBbgvQwVZwlT80w= x-ms-traffictypediagnostic: BLUPR0301MB1556: x-ms-office365-filtering-correlation-id: a5e598cd-c476-4398-b212-08d4a86c15d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0301MB1556; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700073)(100105000095)(100000701073)(100105300095)(100000702073)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703073)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704073)(100105200095)(100000705073)(100105500095); SRVR:BLUPR0301MB1556; BCL:0; PCL:0; RULEID:(100000800073)(100110000095)(100000801073)(100110300095)(100000802073)(100110100095)(100000803073)(100110400095)(100000804073)(100110200095)(100000805073)(100110500095); SRVR:BLUPR0301MB1556; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(39860400002)(13464003)(377454003)(74316002)(53936002)(305945005)(6436002)(38730400002)(2171002)(6246003)(55016002)(76176999)(54356999)(50986999)(7736002)(99286003)(6116002)(102836003)(9686003)(77096006)(14454004)(6506006)(230783001)(8676002)(81166006)(189998001)(2906002)(33656002)(53546009)(3280700002)(2950100002)(25786009)(7696004)(10290500003)(86362001)(3660700001)(478600001)(122556002)(2900100001)(5005710100001)(5660300001)(10090500001)(229853002)(8936002)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1556; H:BLUPR0301MB1554.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2017 21:29:14.0765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1556 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 21:29:19 -0000 I agree with SHOULD & BCP. That is the same language and category we used i= n RFC 6649: Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algor= ithms in Kerberos. Thanks, Michiko Short Program Manager | Authentication Protocols Windows & Devices Group: OS Security -----Original Message----- From: Salz, Rich [mailto:rsalz@akamai.com]=20 Sent: Wednesday, May 31, 2017 5:22 AM To: Benjamin Kaduk ; curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die= -01.txt > At this point, I think the only outstanding questions are whether to=20 > remain as targetting BCP vs. standards track, and semi-relatedly=20 > whether to leave the prohibition against using these enctypes as=20 > SHOULD NOT (to match RFC 6649) or go to the stronger MUST NOT. 6649 is BCP, 7465 is standards-track. I lean towards BCP and SHOULD.

= On Tue, May 9, 2017 at 1:25 PM, Russ Housley <housley@vigilsec.com= > wrote:
>=C2=A0 =C2=A0 The ECC-CMS-SharedInfo entityU= Info field optionally contains
>=C2=A0 =C2=A0 additional keying mater= ial supplied by the sending agent.=C2=A0 Note that
>=C2=A0 =C2=A0 [CM= S] requires implementations to accept a KeyAgreeRecipientInfo
>=C2=A0= =C2=A0 SEQUENCE that includes the ukm field.=C2=A0 If the ukm field is pre= sent,
>=C2=A0 =C2=A0 the ukm is placed in the entityUInfo field.=C2= =A0 The ukm value need not
>=C2=A0 =C2=A0 be longer than the key-encr= yption key that will be produced by the
>=C2=A0 =C2=A0 KDF.
>> Need not? Please clarify what the purpose is here. It seems like
= > it's to generate a unique KEK. In that case, the security bounds> are what, uniqueness?

I suggest this wording:

=C2=A0 = =C2=A0=E2=80=A6 There is no security benefit to using a ukm value that is=C2=A0 =C2=A0longer than the key-encryption key that will be produced by<= br>=C2=A0 =C2=A0the KDF.
=C2=A0
Hmm... I = believe that this statement is true, but it also seems to be<= /div>
incomplete. I may be reasoning about t= his incorrectly, but it seems
to me that the minimal security requirement is that the UKM be=
unique, but that can be achiev= ed with a value much smaller than
=
the KEK. For instance, it seems like if you have a 256-bit KEK,
then you would still be O= K with a randomly-generated 128-bit
UKM. And if we're concerned about random collisions, then t= he
usefulness bound is a= ctually min(|KEK|, |hash compression function size|).
=C2=A0<= u>
Yes. The umm value needs to be diffe= rent for each invocation of the KDF, otherwise it does not provide the assu= rance that different keying material will be produced.=C2=A0 Of course, an = implementation will generate the umm value using random number generator, n= ot track the values that are used.=C2=A0 Several years ago, there was a dis= cussion about the size of the ukm needed.=C2=A0 Some people were suggesting= crazy large values, and the point was made that anything beyond the SIZEOF= (KEK) did not improve security.
=C2=A0
Are you a= sking for a sentence saying that the ukm, if present, MUST be at least 128 = bits?
=C2=A0
[JLS] I would disagree that the value has to be random, a counter will wo= rk as well.=C2=A0 (An encrypted counter is better.)=C2=A0 I not be happy wi= th a fixed size requirement on this easier.=C2=A0 There is no reason to mak= e such a requirement that I can think of.=C2=A0 A 64-bit counter is just as= rational.=C2=A0 It might make more sense to change this statement into som= ething along the lines of=C2=A0
=C2=A0
* Any pair of static keys = MUST NOT be used more times than the size of the key.=C2=A0 I.e. if 128-bit= KEKs may be used, then there is a 2^128 limit on the number of times the k= ey pair can be used.
* The size of the KEK is normally not longer = than the length of the resulting KEK as that is the limit of unique values = that can be generated in any event.
<= /div>
=C2=A0
= Section 2 already says that the ephemeral key MUST be used for only one mes= sage.=C2=A0 Thus, a UKM is not really needed.=C2=A0 However, the CMS requir= es support for a UKM if the sender include it.=C2=A0 For this reason, the d= ocument says how to handle it in the KDF if it is present.
=C2=A0
You = are correct that a counter, encrypted counter, or random value will work, e= ven if the originator uses the same ephemeral key for many messages.=C2=A0 = The text does not limit the choices in any way.
=C2=A0
The text alread= y says that there is no security reason for a UKM value that is longer than= the KEK.=C2=A0 I think that EKR is asking for guidance on the minimum size= too.
=C2=A0
[JLS] It=E2=80=99s kind of a stupid thing = to do, but the minimum size would be one bit.=C2=A0 Although this is not le= gal from an ASN.1 standpoint =E2=80=93 so the minimum would be one byte.=C2=A0
=C2=A0
A= single byte with all bits zero and two bytes with all bits zero are differ= ent ukm values because of the way that they are used in the ECC-CMS-SharedI= nfo structure.=C2=A0 Note that this would not be the case if the ukm value = was only used as a salt value to HKDF.=C2=A0 I do not see any reason to spe= cify a minimum length of this value.=C2=A0 The only thing that is required = is uniqueness, EKR is correct about saying this.=C2=A0