From nobody Fri Sep 1 06:56: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 C91D213328B; Fri, 1 Sep 2017 06:55:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: curdle@ietf.org, draft-ietf-curdle-rsa-sha2.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150427414878.3237.4575033946525642940@ietfa.amsl.com> Date: Fri, 01 Sep 2017 06:55:48 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10 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, 01 Sep 2017 13:55:49 -0000 Reviewer: Russ Housley Review result: Almost Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-curdle-rsa-sha2-10 Reviewer: Russ Housley Review Date: 2017-09-01 IETF LC End Date: 2017-09-11 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: None Minor Concerns: I think that a better title for this document would be: Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) These are two of the hash function in the SHA2 family, and there is no ambiguity about them being part of the SHA3 family. Similarly, I think that the Abstract and Section 1 should explicitly names these two hash functions. The current wording seems to include SHA-224 and SHA-384, and that is not the intent of the author. In Section 3, I suggest: s/using SHA-2 [SHS] as hash./using SHA-256 or SHA-512 [SHS] as hash./ s/the hash used is SHA-2 256./the hash used is SHA-256./ s/the hash used is SHA-2 512./the hash used is SHA-512./ Note: I did not propose changing the strings in case people have already implemented against this specification. If no one has implemented yet, then I would change those too. Section 5.1 should be expanded to say that following the NIST advice on key sizes and SHA-1 outside the US Government is prudent. Nits: None From nobody Sat Sep 2 01:28: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 E1224132EC2; Sat, 2 Sep 2017 01:27:58 -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 vVqjc5tZhT_n; Sat, 2 Sep 2017 01:27:57 -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 992D2132E5F; Sat, 2 Sep 2017 01:27:53 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id a126so7258166lfa.0; Sat, 02 Sep 2017 01:27: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=H9l5RqPS8fC5xXB4YONQh8iqj2A1Cl+H/nqq9kMiMNg=; b=QyW1BQNq0STQpgIdhhmZmE5bwPf0tAvAzA5D4h0cxeMtvXeQz9qbnJsh4NDJ9HZPs3 RSdBS8uBCjBv9r9y3jMy6L6JWDlAI58FUgqT3XdMLjj6pAly4EWf0evee4qUbodCSnp2 LFT570LQKJ2jcmX8NKw7N3W5RVShf0Zx/9SJY1/mokDMP05r1k3wazAAhAxpsIHyNloA jJ16jotZbKyRrp/C8TVsKZ7s/Fp6x7+cdqUE5vxATrHBLpA3uic/mpariMYYL89LPKZC XRctTGhTOlBrrQPA1hFJ8tiSR0kWM63vsWpO36fR48XQImtYLVIEFW00ki6JNol1ecI1 Vgvw== 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=H9l5RqPS8fC5xXB4YONQh8iqj2A1Cl+H/nqq9kMiMNg=; b=A05ZrNnBwZ3dPXKZUVLo2ymMCZ3pyP+2v63ernrWtLsSNe4hOZwgNJe/znGRQBzWrd 7pynxzGwPWjgqPxolDWXWdi41CvQtV0mDAjUQuVEhQ0gLH8dEZvjxcWrNfvrhIaJke5Z N8ALGeW//7FWP6ueRLl3gHf7eNHRvTYpLiipfCIEKmQTkkeVtGgSQt3JgdQUPnpZE2WI ZtxjwkzctOhjxLssbPLZADJ4cs8treGzduk16ynqaWdvGbBVsVRlj3ImZeZ8Lrmzkb7n uwCAuSf1PT1j08FSkrTn0SSPTbMvW00KowE0NzjYYgKw2mipKTqFCPYAt/10bgAus7Bg k9GQ== X-Gm-Message-State: AHPjjUgYjx33LhmMt01/6I+sjdbl+owGvageDhkWnWjkyf6ck49M4Btb /06NIHyJZQk4xXUZsnwjqPWZU2550FkC X-Google-Smtp-Source: ADKCNb65AxuXQgiEdPfgwvsYp9ny4ebkj23Yza5C6bwD+K1vujZqeRXZRDqj+/TdE2OG98jFPYujCGXjlbgyX3Ts/H0= X-Received: by 10.25.222.143 with SMTP id i15mr258450lfl.4.1504340871822; Sat, 02 Sep 2017 01:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Sat, 2 Sep 2017 01:27:51 -0700 (PDT) In-Reply-To: <150427414878.3237.4575033946525642940@ietfa.amsl.com> References: <150427414878.3237.4575033946525642940@ietfa.amsl.com> From: denis bider Date: Sat, 2 Sep 2017 03:27:51 -0500 Message-ID: To: Russ Housley Cc: gen-art@ietf.org, curdle , draft-ietf-curdle-rsa-sha2.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="f403045fa78c494409055830a7fe" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Sep 2017 08:27:59 -0000 --f403045fa78c494409055830a7fe Content-Type: text/plain; charset="UTF-8" Hello Russ, thank you for the review. Comments: > I think that a better title for this document would be: > Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) I can make this change, but I should note this is not universally agreed on. In a previous specification, which became RFC 6668: https://www.ietf.org/rfc/rfc6668.txt ... the original draft called for e.g. "hmac-sha256", but there were immediate concerns about ambiguity which led to "hmac-sha2-256" and "hmac-sha2-512" being specified. > The current wording seems to include SHA-224 and SHA-384, > and that is not the intent of the author. True, but in this case as well, I point out RFC 6668, where we have the title: "SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol" ... even though the document only specifies "hmac-sha2-256" and "hmac-sha2-512". It appears to me that it may not be necessary for a document to specify use of all versions of SHA-2, in order to be accurately described as specifying the use of SHA-2 in a context. > I did not propose changing the strings in case people have > already implemented against this specification. If no one > has implemented yet, then I would change those too. This intuition is correct. It has been widely implemented and is deployed on, very possibly, millions of systems. One can launch an off-the-shelf Amazon instance that has a long-term-support edition of Ubuntu with a version of OpenSSH that implements this. > Section 5.1 should be expanded to say that following the NIST > advice on key sizes and SHA-1 outside the US Government is > prudent. I can do this. As instructed, I await instructions from the document shepherd. denis On Fri, Sep 1, 2017 at 8:55 AM, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > . > > Document: draft-ietf-curdle-rsa-sha2-10 > Reviewer: Russ Housley > Review Date: 2017-09-01 > IETF LC End Date: 2017-09-11 > IESG Telechat date: unknown > > Summary: Almost Ready > > Major Concerns: None > > > Minor Concerns: > > I think that a better title for this document would be: > > Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) > > These are two of the hash function in the SHA2 family, and there is no > ambiguity about them being part of the SHA3 family. Similarly, I think > that the Abstract and Section 1 should explicitly names these two hash > functions. The current wording seems to include SHA-224 and SHA-384, > and that is not the intent of the author. > > In Section 3, I suggest: > s/using SHA-2 [SHS] as hash./using SHA-256 or SHA-512 [SHS] as hash./ > s/the hash used is SHA-2 256./the hash used is SHA-256./ > s/the hash used is SHA-2 512./the hash used is SHA-512./ > > Note: I did not propose changing the strings in case people have already > implemented against this specification. If no one has implemented yet, > then I would change those too. > > > Section 5.1 should be expanded to say that following the NIST advice on > key sizes and SHA-1 outside the US Government is prudent. > > > Nits: None > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045fa78c494409055830a7fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Russ,

thank you for the review. C= omments:


>=C2=A0I think that a better title for this document would be:
> Use of RSA Keys with SHA-25= 6 and SHA-512 in Secure Shell (SSH)

I can make this change, but I should note this is not unive= rsally agreed on. In a previous specification, which became RFC 6668:


.= .. the original draft called for e.g. "hmac-sha256", but there we= re immediate concerns about ambiguity which led to "hmac-sha2-256"= ; and "hmac-sha2-512" being specified.


>=C2=A0The cu= rrent wording seems to include SHA-224 and SHA-384,
> and that is not the intent of the author.=

True, but in this case as = well, I point out RFC 6668, where we have the title:

"SHA-2 Data Integrity Verification for the Secure Shell (SSH) = Transport Layer Protocol"

... even t= hough the document only specifies "hmac-sha2-256" and "hmac-= sha2-512".

It appears to me that it may = not be necessary for a document to specify use of all versions of SHA-2, in= order to be accurately described as specifying the use of SHA-2 in a conte= xt.


>=C2=A0I did not p= ropose changing the strings in case people have
> already=C2=A0implemented against this specification.=C2=A0 If no one
<= div>> has implemented yet,=C2=A0= then I would change those too.

This intuition is correct. It has been widely implemente= d and is deployed on, very possibly, millions of systems. One can launch an= off-the-shelf Amazon instance that has a long-term-support edition of Ubun= tu with a version of OpenSSH that implements this.


>=C2=A0Section 5.1 should be expanded to say t= hat following the NIST
&g= t; advice on=C2=A0key sizes and SHA= -1 outside the US Government is
> prudent.

=
I can do this.


As instructed, I await instructions from the document shepherd.

denis


=

On Fri, Sep= 1, 2017 at 8:55 AM, Russ Housley <housley@vigilsec.com> = wrote:
Reviewer: Russ Housley
Review result: Almost Ready

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/= trac/wiki/GenArtfaq>.

Document: draft-ietf-curdle-rsa-sha2-10
Reviewer: Russ Housley
Review Date: 2017-09-01
IETF LC End Date: 2017-09-11
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns: None


Minor Concerns:

I think that a better title for this document would be:

=C2=A0 =C2=A0Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH)=

These are two of the hash function in the SHA2 family, and there is no
ambiguity about them being part of the SHA3 family.=C2=A0 Similarly, I thin= k
that the Abstract and Section 1 should explicitly names these two hash
functions.=C2=A0 The current wording seems to include SHA-224 and SHA-384,<= br> and that is not the intent of the author.

In Section 3, I suggest:
=C2=A0 =C2=A0s/using SHA-2 [SHS] as hash./using SHA-256 or SHA-512 [SHS] as= hash./
=C2=A0 =C2=A0s/the hash used is SHA-2 256./the hash used is SHA-256./
=C2=A0 =C2=A0s/the hash used is SHA-2 512./the hash used is SHA-512./

Note:=C2=A0 I did not propose changing the strings in case people have alre= ady
implemented against this specification.=C2=A0 If no one has implemented yet= ,
then I would change those too.


Section 5.1 should be expanded to say that following the NIST advice on
key sizes and SHA-1 outside the US Government is prudent.


Nits: None


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

--f403045fa78c494409055830a7fe-- From nobody Sun Sep 3 14:27:08 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAB613240D for ; Sun, 3 Sep 2017 14:27:07 -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 ATPHT6iPhhqr for ; Sun, 3 Sep 2017 14:27:05 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1354C13233D for ; Sun, 3 Sep 2017 14:27:05 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h127so18313942ywf.3 for ; Sun, 03 Sep 2017 14:27:05 -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=MbEF/viVtBuEOezX9Os1y/RKsdeKG1W/NyYEFRLXjkk=; b=iUrFyT3DkYhhHAXb04AqgnkvHcXicwW/PQA+reADLIwu78u8qtDoudAvCpIujV4PcS qYsgjhiPwFOXWCTch4NG0KVI1klqVKYr5Iss/xiuiMBFItB9+lCXQw40G3N1imvQBNc3 S4EVMvbtMlb7H+4Y2XLFYu/lEWS9iuPiISsg6KJkguR36Ze1hDTUp5o2ZLYj8ZP2cgVC 9BTYMBaeh3zspV7b14rnDUftz03v5EySHIicB7k5Q5YIwtvCzinVLwkzZI3cas92yX2R ML8hfopmgMw0wQFCMv97W9voY90MaqgM8bROJ4x7XkjA50PKhIB/ephx/lo/x3Y3nRVc /SkQ== 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=MbEF/viVtBuEOezX9Os1y/RKsdeKG1W/NyYEFRLXjkk=; b=eRXydtDzyb4NQakcp3WLMT8hia1fYNm0zUQTZcNkis1IgZSkIL1oEY6Jb6QbDqISny VNGSDLAxrDa3UjTq0aWfOE6SqV/NzAY24I/OKvk1S23wmkZ1QBXn28L7E+FZp5sgaKgs 0xG5FYkVuFeRmrKbg1lm+PgVB3Ie5Vdtjx9aT8U23SZGOxJ75dU7VBAIf+4k+CYCKYE+ kkrX7Ds4g2DyIHT49aSga+VyYN5oQEoxle9qZeC5OsR8Etl6FVb2muo79d9r57xDT51E tgKhvlL9t8iIhMVgqL9FnMiwKvpe6beZw504RxOrChJiNmgS1otkWGReZ8ynvS4qFlb+ 9dwA== X-Gm-Message-State: AHPjjUjFoQJleocAGNlK5d50PiS7GpeVOYO+x60D2cj9paa5tx415DvC 7WNkwYuCd9mCuMaykfU4CbLJwM6ykLfyqRE= X-Google-Smtp-Source: ADKCNb77zYjAGTNbJtxNjAw3syq2NrR6dbV+HEIXr23PWf/m/J2XfV3sbKxGXZHpWOzdx6OmoCeMerbdvcRz6IVgD+w= X-Received: by 10.129.216.13 with SMTP id d13mr6072489ywj.270.1504474024086; Sun, 03 Sep 2017 14:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sun, 3 Sep 2017 14:26:23 -0700 (PDT) From: Eric Rescorla Date: Sun, 3 Sep 2017 14:26:23 -0700 Message-ID: To: curdle , draft-ietf-curdle-pkix@tools.ietf.org Content-Type: multipart/alternative; boundary="089e0821f204c7a40205584fa798" Archived-At: Subject: [Curdle] AD Review: draft-ietf-curdle-pkix-05 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 21:27:07 -0000 --089e0821f204c7a40205584fa798 Content-Type: text/plain; charset="UTF-8" Hi folks, As the chairs and I discussed, we're experimenting with AD reviews with Phabricator. I've stood up an instance at https://mozphab-ietf.devsvcdev.mozaws.net/ and reviewed this draft. As you can see, comments appear here in HTML, but you can see in context by clicking on the various links in the e-mail. We're still hashing out the workflow, but.... 1. If you make an account and login, you can respond to the comments and we can try to resolve them before you produce a new draft. 2. When you're ready to produce a new draft, you can either upload it to the draft repo or send me the pre-draft and either way I'll take care of getting it uploaded here, so we can see diffs, etc. Let me know if you run into problems. There are definitely a few rough edges here (partly because Phabricator is for code review) but I've used this type of tool very extensively and it's much easier to work with than email comments once you get used to it. Thanks, -Ekr ekr requested changes to this revision. ekr added inline comments. This revision now requires changes to proceed. View Revision *INLINE COMMENTS* View Inline draft-ietf-curdle-pkix.txt:281 ..., [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]], ... This actually doesn't replicate 5958, which doesn't have the IMPLICIT, and I don't see an erratum for this (though maybe I missed it?). So probably some revised text is needed. View Inline draft-ietf-curdle-pkix.txt:287 PublicKey ::= BIT STRING Nice catch. View Inline draft-ietf-curdle-pkix.txt:320 Z9w7lshQhqowtrbLDFw4rXAxZuE= -----END PRIVATE KEY------ NOTE: There exist some private key import functions that have not You're going to want some whitespace here, I think. View Inline draft-ietf-curdle-pkix.txt:325 structure which contains the public key field. This means a balancing act needs to be done between being able to do a consitency check on the key pair and widest ability to import the key. Nit: consistency. View Inline draft-ietf-curdle-pkix.txt:601 Z9w7lshQhqowtrbLDFw4rXAxZuE= -----END PRIVATE KEY----- The same item dumped as asn1 yields: Add whitespace. View Inline draft-ietf-curdle-pkix.txt:650 The procedures for going from a private key to a public key is different for when used with Diffie-Hellman and when used with Nit: are different View Inline draft-ietf-curdle-pkix.txt:740 The following is not an invalid encoding, but it may not be accepted by many systems as it is BER encoded. Probably not great to have the sentence above say that this is a sampling of incorrect keys and then have a valid one. View Inline draft-ietf-curdle-pkix.txt:748 In the following example, the private key does not match the masking requirements for X25519. For this example the top top bits are set to zero and the low three bits are set to 001. top top. also, I would say top/bottom or high/low. View Inline draft-ietf-curdle-pkix.txt:757 In the following examples, the key is the wrong length because an all zero byte has been removed. I assume a leading all zero byte? View Inline draft-ietf-curdle-pkix.txt:767 IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk -----END PRIVATE KEY----- What is the difference between these two? *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D28 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr *Cc: *ekr, ekr-webrtc --089e0821f204c7a40205584fa798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi f= olks,

= As the chairs and I discussed, we're experimenting with AD reviews
with Phabricator.=C2=A0 I've stood up an in= stance at
https://mozphab-ietf.devsvcdev.mozaws.net/ and re= viewed this draft. As
you can see, comments= appear here in HTML, but you can see in context
by clicking on the various links in the e-mail.

We're still hashing out= the workflow, but....

1. If you make an account and login, you can respond to th= e comments
and we can try to resolve them b= efore you produce a new draft.

2. When you're ready to produce a new draft, y= ou can either upload
it to the draft repo o= r send me the pre-draft and either way I'll
take care of getting it uploaded here, so we can see diffs, etc.
=

Let me know= if you run into problems. There are definitely a few rough
edges here (partly because Phabricator is for code review)= but I've
used this type of tool very e= xtensively and it's much easier to work
with than email comments once you get used to it.

Thanks,
-Ekr


ekr requested = changes to this revision.
ekr added inline comments.
This revision no= w requires changes to proceed. 		View Revision
INLINE COMMENTS
View Inline= draft-ietf-curdle-pkix.txt:281
...,
[[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
...

This actually doesn't replicate 5958, which doesn't have th= e IMPLICIT, and I don't see an erratum for this (though maybe I missed = it?). So probably some revised text is needed.


View = Inlinedraft-ietf-c= urdle-pkix.txt:287
PublicKey ::=3D BIT STRING

Nice catch.


View Inlinedraft-ietf-curdle-pkix.txt:320
Z9w7lshQhqowtrbLDFw4rXAxZuE=3D
-----END PRIVATE KEY------
NOTE: There exist some private key import functions that have = not

You're going to want some whitespace here, I think.


=
View Inlinedraft-ietf-curdle-pkix.txt:325
structure which contains the public key field. This means a
balancing act needs to be done between being able to do a cons= itency
check on the key pair and widest ability to import the key.

Nit: consistency.


View Inlinedraft-ietf-curdle-pkix.txt:6= 01
Z9w7lshQhqowtrbLDFw4rXAxZuE=3D
-----END PRIVATE KEY-----
The same item dumped as asn1 yields:

Add whitespace.


View Inlinedraft-ietf-curdle-pkix.txt:6= 50
The procedures for going from a private key to a public key is
different for when used with Diffie-Hellman and when used with

Nit: are different


View Inlinedraft-ietf-curdle-pkix.txt:= 740
The following is not an invalid encoding, but it may not be accept= ed
by many systems as it is BER encoded.

Probably not great to have the sentence above say that this is a sa= mpling of incorrect keys and then have a valid one.


View Inlinedraft= -ietf-curdle-pkix.txt:748
In the following example, the private key does not match the maski= ng
requirements for X25519. For this example the top top bits ar= e set
to zero and the low three bits are set to 001.

top top. also, I would say top/bottom or high/low.

<= br>
View Inline= draft-ietf-curdle-pkix.txt:757
In the following examples, the key is the wrong length because an = all
zero byte has been removed.

I assume a leading all zero byte?


View Inli= nedraft-ietf-curdl= e-pkix.txt:767
IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
-----END PRIVATE KEY-----

What is the difference between these two?


REPOSITORY
rIETFREVIEW ietf-review


EMAIL PREFERENCES
https://mozphab-ietf.de= vsvcdev.mozaws.net/settings/panel/emailpreferences/
To: ekr-moz, ekr
Cc: ekr,= ekr-webrtc

--089e0821f204c7a40205584fa798-- From nobody Mon Sep 4 03:23:24 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 C7FDC1321AA; Mon, 4 Sep 2017 03:23:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150452059681.548.5020716568283289876.idtracker@ietfa.amsl.com> Date: Mon, 04 Sep 2017 03:23:16 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-cur?= =?utf-8?q?dle-ssh-dh-group-exchange-05=3A_=28with_COMMENT=29?= 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, 04 Sep 2017 10:23:17 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Can you explain why the pre-5378 boilerplate is used? 2) I guess RFC4419 should be a normative reference! From nobody Mon Sep 4 04:42:57 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 D67121241FC; Mon, 4 Sep 2017 04:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150452537587.499.7020645960000786889.idtracker@ietfa.amsl.com> Date: Mon, 04 Sep 2017 04:42:55 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-curdle-ssh-modp-dh-sha2-07=3A_=28with_COMMENT=29?= 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, 04 Sep 2017 11:42:56 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) To me this sentence does not belong in the IANA section as it is basically the main point of the document: "This document augments the Key Exchange Method Names in [RFC4253] and [RFC4250]." Maybe move it to sec 3? 2) Can you explain why the pre-5378 boilerplate is used? From nobody Mon Sep 4 05:18:37 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A39126DD9; Mon, 4 Sep 2017 05:18:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150452751108.452.17402297157409789400.idtracker@ietfa.amsl.com> Date: Mon, 04 Sep 2017 05:18:31 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-curdle-ssh-ext-info-12=3A_=28with_COMMENT=29?= 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, 04 Sep 2017 12:18:31 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two? 2) One question regarding flow control: I understood that some implementation simply set the max value for the initial window, however, if you don't even have a max window how do you ensure that the receiver is not over loaded and what do you do if you receive more data that you can handle? 3) I'm by far not an expert but I would have expected that there are additional security consideration for elevation and mybe even flow control... no? 4) Thanks for quickly addressing the genart review! From nobody Mon Sep 4 06:47: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 41285132191; Mon, 4 Sep 2017 06:47:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> Date: Mon, 04 Sep 2017 06:47:46 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= 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, 04 Sep 2017 13:47:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-des-des-des-die-die-die-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is mainly a processing question, so probably more for the IESG to discuss than the authors: I understand the intention of obsoleting RFC4757 to declare that the algorithms described should not be used anymore, however, rfc4757 is an informational implementation description which is probably still deployed. Obsoleting an informational implementation description seems a bit weird. Just would like to double-check with the rest of the IESG if that action appropriate...? Also obsoleting and moving to historic is not the same thing. The document says: "This document recommends the reclassification of [RFC4757] as Historic." One of the two actions (obsoleting or moving to historic) is enough. While I think moving to historic might actually be more appropriate than obsoleting an implementation description, it should only be moved to historic if this is not used and deployed anymore. Also moving to historic also requires a status change action. From nobody Mon Sep 4 18:16:15 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2097E1321D5; Mon, 4 Sep 2017 18:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjssg8_AFREh; Mon, 4 Sep 2017 18:16:11 -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 73F711321C7; Mon, 4 Sep 2017 18:16:08 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id 80so1342413lfy.4; Mon, 04 Sep 2017 18:16: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; bh=qaPq6osrdhfkKuP92hvNmeKKQ2lU1go+eOsZO8lw2cI=; b=E/pA8QI4o69uW2rooJtwHniF/284kVvej/YIStSqeZDLIyQ+CayAZ2KKoYrFfeqOVn hYPQWXraoBuoiFp0DTSfqb5mg+BxSMf3ZHpxqT9t9crZrd9XmndjVgMSmkyrthOT0cU3 HwCq+HkgjPAWZXPzYaxrVN84RXkBEo5qbQac/ZGx+WbV9j5gq9xU8J/SIuvyDYfIknnw WOviDgmzwKE8XHM7Esi2Id2iQ80Kas7dimeuIB10cSylnbOK6nETwPPfJrp5SUQiykeo JDuumKSlg3MuR+EDsoz9A31eabZGF3nDIQve8Sm4BnTmMC9mN8CyH36e0rUWVWNvwtLB QwaA== 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=qaPq6osrdhfkKuP92hvNmeKKQ2lU1go+eOsZO8lw2cI=; b=AUwGpbmHJOmeipmvIeagbfMD0/8xibvTNd4lt3KCNF9ZTycFKcYH7FFvNUdqY7ZICm gL2MoBcM7HYRYkPOODfIa7XwGy8uqkFj8beGavZCGZPHkOVNFYRmFVCgtTp/Hb3O3Wm8 2hk9ZOrkUnIuay9VsJoK4J63aZyKpAq03DFz/2Xma3SEf7xjXhGU1cSwgnhv7K2/BXsH ZJuyhEm3VuggQhxSBpWOI+3bgYRv5kQ14JUGaZ1ZSNLwvRZn0jqRTrMe29OEAJRk8JgN 0f49yZk+xMS31NkOkXbmY06m4p0VEdEJGNTxEYOAOYfwukels824RrWISdme3GdrZLls 3LSA== X-Gm-Message-State: AHPjjUi53dmm/58nuJWBFEtFVkM3k0Pp6ewLBzFV2VZBLIdaHzTsZpfj RZgnVMnEx372AosCljLZxp0Mn4dViqE/ X-Google-Smtp-Source: ADKCNb4lvF+V0QQCqXvfqVd5p75x3fe1dDgdzkLPAWOrn9LATKt40hdfq8sEDFAM+oWUoWY4RRCd8vPx4HwqmVe/Apk= X-Received: by 10.25.1.4 with SMTP id 4mr165095lfb.78.1504574166723; Mon, 04 Sep 2017 18:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Mon, 4 Sep 2017 18:16:06 -0700 (PDT) In-Reply-To: <150452751108.452.17402297157409789400.idtracker@ietfa.amsl.com> References: <150452751108.452.17402297157409789400.idtracker@ietfa.amsl.com> From: denis bider Date: Mon, 4 Sep 2017 20:16:06 -0500 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a113a3edebef2eb055866f8e2" Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-curdle-ssh-ext-info-12=3A_=28with_COMMENT=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Sep 2017 01:16:14 -0000 --001a113a3edebef2eb055866f8e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mirja: > What happens if the server received more than one (different) > EXT_INFO messages or the client receives more than two? Such sender behavior is incorrect according to the spec. Receiver behavior is implementation dependent. In the absence of a specific reason to do so, I think it's counter-productive to define receiver behavior for all possible ways a sender could violate the spec. It complicates both the implementation and the spec. It seems best to let implementations handle that in whatever way is convenient. > One question regarding flow control: I understood that some > implementation simply set the max value for the initial window, > however, if you don't even have a max window how do you > ensure that the receiver is not over loaded and what do you > do if you receive more data that you can handle? The max value hack and the no-flow-control extension behave similarly until 4 GB of data is transferred. When amount of data transferred approaches 4 GB, the max value hack has to send a window adjust, whereas an implementation using the no-flow-control extension can just keep going. In both cases, flow control is provided by TCP. If the receiver can't handle the data, it doesn't read it from the socket. It is for this reason that the no-flow-control extension specifies there can be at most one SSH channel at a time when this extension is in effect. The TCP flow control only works satisfactorily with a single channel. In my view at least, applications that implement multiple channels should implement proper per-channel flow control as originally specified by SSH. > I'm by far not an expert but I would have expected that > there are additional security consideration for elevation > and mybe even flow control... no? Not that I know of. There's certainly no impact on flow control. If there's a security consideration, it's that this extension would be nice for everyone to implement - including vendors who hate Windows - so that SSH sessions made by administrators to Windows servers could be established without elevation by default; and with elevation only if requested by the user (e.g. through a client command line flag). Presently, without this extension, SSH sessions made by administrators to Windows servers have to always be elevated by the SSH server by default. This decision needs to be made before authentication, because after authentication, the security context for the session is already constructed. If there's no way for the client to indicate this choice, the server always needs to create an elevated session in case the user wants to exercise their administrative access. If this extension is supported, the user has the option to request no elevation, e.g. because they know they're only going to need their regular use permissions, not their administrative access. If the extension were to become universally supported, then no elevation (being the safer choice) could become the server-side default. On Mon, Sep 4, 2017 at 7:18 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) What happens if the server received more than one (different) EXT_INFO > messages or the client receives more than two? > > 2) One question regarding flow control: I understood that some > implementation > simply set the max value for the initial window, however, if you don't ev= en > have a max window how do you ensure that the receiver is not over loaded > and > what do you do if you receive more data that you can handle? > > 3) I'm by far not an expert but I would have expected that there are > additional > security consideration for elevation and mybe even flow control... no? > > 4) Thanks for quickly addressing the genart review! > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113a3edebef2eb055866f8e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mirja:


>=C2=A0<= span style=3D"font-size:12.8px">What happens if the server received more th= an one (different)
> E= XT_INFO=C2=A0messages or the client= receives more than two?

Such sender behavior is= incorrect according to the spec. Receiver behavior is implementation depen= dent.

In the absence of a specific reason to do so, I th= ink it's counter-productive to define receiver behavior for all possibl= e ways a sender could violate the spec. It complicates both the implementat= ion and the spec. It seems best to let implementations handle that in whate= ver way is convenient.


>=C2=A0One question regarding flow control: I under= stood that some
> impl= ementation=C2=A0simply set the max = value for the initial window,
> however, if you don't even=C2=A0have a max window how do you
> ensure that the receiver is not over loaded and=C2=A0what do you
> do if you receive more data that you can hand= le?

The max value hac= k and the no-flow-control extension behave similarly until 4 GB of data is = transferred. When amount of data transferred approaches 4 GB, the max value= hack has to send a window adjust, whereas an implementation using the no-f= low-control extension can just keep going.

In both= cases, flow control is provided by TCP. If the receiver can't handle t= he data, it doesn't read it from the socket.

I= t is for this reason that the no-flow-control extension specifies there can= be at most one SSH channel at a time when this extension is in effect. The= TCP flow control only works satisfactorily with a single channel. In my vi= ew at least, applications that implement multiple channels should implement= proper per-channel flow control as originally specified by SSH.
=

>=C2=A0= =C2=A0I'm by far not an expert = but I would have expected that
> there are additional=C2=A0security consideration for elevation
> and mybe even flow control... no?

<= /div>
Not that I know of. There's certainly no impact on flow contr= ol.

If there's a security consideration, it= 9;s that this extension would be nice for everyone to implement - including= vendors who hate Windows - so that SSH sessions made by administrators to = Windows servers could be established without elevation by default; and with= elevation only if requested by the user (e.g. through a client command lin= e flag).

Presently, without this extension, SSH se= ssions made by administrators to Windows servers have to always be elevated= by the SSH server by default. This decision needs to be made before authen= tication, because after authentication, the security context for the sessio= n is already constructed. If there's no way for the client to indicate = this choice, the server always needs to create an elevated session in case = the user wants to exercise their administrative access.

If this extension is supported, the user has the option to request no= elevation, e.g. because they know they're only going to need their reg= ular use permissions, not their administrative access. If the extension wer= e to become universally supported, then no elevation (being the safer choic= e) could become the server-side default.



On Mon, Se= p 4, 2017 at 7:18 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net><= /span> wrote:
Mirja K=C3=BChlewind has en= tered the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question regarding flow control: I understood that some implementati= on
simply set the max value for the initial window, however, if you don't = even
have a max window how do you ensure that the receiver is not over loaded an= d
what do you do if you receive more data that you can handle?

3) I'm by far not an expert but I would have expected that there are ad= ditional
security consideration for elevation and mybe even flow control... no?

4) Thanks for quickly addressing the genart review!


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

--001a113a3edebef2eb055866f8e2-- From nobody Tue Sep 5 01:34:35 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1413271E; Tue, 5 Sep 2017 01:34:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mehmet Ersue To: Cc: curdle@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150460047380.28645.3168889127868551818@ietfa.amsl.com> Date: Tue, 05 Sep 2017 01:34:33 -0700 Archived-At: Subject: [Curdle] Opsdir telechat review of draft-ietf-curdle-ssh-ext-info-10 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, 05 Sep 2017 08:34:34 -0000 Reviewer: Mehmet Ersue Review result: Has Nits I reviewed the document "Extension Negotiation in Secure Shell (SSH)" (draft-ietf-curdle-ssh-ext-info-10.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Updates: 4252, 4253, 4254 (if approved) Current IESG state: In Last Call (ends 2017-07-30) IANA State: IANA OK - IANA will act upon approval of the document Summary: The document 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. There are a few nits in the document. ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC8126) The document does not cause any issues related to operations and management and looks ready for publication. Mehmet From nobody Tue Sep 5 09:13: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 DB8F5132D43 for ; Tue, 5 Sep 2017 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 apuK5eq40C7R for ; Tue, 5 Sep 2017 09:13:52 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5D971132D81 for ; Tue, 5 Sep 2017 09:13:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id D6C225371C; Tue, 5 Sep 2017 19:13:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Oirsg5Dyjcu4; Tue, 5 Sep 2017 19:13:49 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4D1882313; Tue, 5 Sep 2017 19:13:46 +0300 (EEST) Date: Tue, 5 Sep 2017 19:13:45 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: curdle , draft-ietf-curdle-pkix@tools.ietf.org Message-ID: <20170905161345.hw5bql53xocmow4h@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-pkix-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, 05 Sep 2017 16:13:55 -0000 On Sun, Sep 03, 2017 at 02:26:23PM -0700, Eric Rescorla wrote: > top top. also, I would say top/bottom or high/low. > > View Inline > draft-ietf-curdle-pkix.txt:757 > In the following examples, the key is the wrong length because an all > zero byte has been removed. > > I assume a leading all zero byte? > > View Inline > draft-ietf-curdle-pkix.txt:767 > IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk > -----END PRIVATE KEY----- > > What is the difference between these two? I Took a look at this: Both seem to be missing one octet from public key, the first one looks to be missing the first (least significant!) octet, and the second one seems to be missing the last (most significant) octet. Computing the public keys from the private keys, I get (C); with encoded public keys (E): C: 00c17e4d8bbff27c1fb618c23fce988703c7efa3cd590aacac12d3f1e3c90c8c E: C17E4D8BBFF27C1FB618C23FCE988703C7EFA3CD590AACAC12D3F1E3C90C8C And: C: 9d421270ce2fcc08672c41e427214876245c9b0f14ab671b8bb9d266a492e400 E: 9D421270CE2FCC08672C41E427214876245C9B0F14AB671B8BB9D266A492E4 -Ilari From nobody Sat Sep 9 19:03: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 C7661128D0F; Sat, 9 Sep 2017 19:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 nwhAwGig6TlO; Sat, 9 Sep 2017 19:03:00 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0090.outbound.protection.outlook.com [104.47.41.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABED3132397; Sat, 9 Sep 2017 19:03:00 -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=5rdO6Kvp/NSpXwZrr6iWwXvdoJHyNGA1WVIsutT/mIA=; b=c+wH9MFTrL95XgoSEAhKfCG3UjozWWQy4M0XEhFxtnjAEjCiSNS4IU+qnn8Zzf71ssEc4B4fKDhwDShdxaN39Q8i/Tf3bXR3+Llor0YBBWY3PEDmPh08F3laABPJ91iBazrsJRcQUWVULtuO+7hIjF6T2wqF9WuGEwBphPNi1kI= Received: from BLUPR05CA0060.namprd05.prod.outlook.com (10.141.20.30) by CY4PR05MB3525.namprd05.prod.outlook.com (10.171.244.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Sun, 10 Sep 2017 02:02:59 +0000 Received: from CO1NAM05FT046.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::209) by BLUPR05CA0060.outlook.office365.com (2a01:111:e400:855::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.56.4 via Frontend Transport; Sun, 10 Sep 2017 02:02:58 +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 CO1NAM05FT046.mail.protection.outlook.com (10.152.96.161) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1385.11 via Frontend Transport; Sun, 10 Sep 2017 02:02:57 +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, 9 Sep 2017 19:02:57 -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 v8A22t19012068; Sat, 9 Sep 2017 19:02:55 -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 B5F0F11446; Sat, 9 Sep 2017 19:02:54 -0700 (PDT) To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= CC: The IESG , , , , In-Reply-To: <150452537587.499.7020645960000786889.idtracker@ietfa.amsl.com> References: <150452537587.499.7020645960000786889.idtracker@ietfa.amsl.com> Comments: In-reply-to: =?us-ascii?Q?=3D=3Futf-8=3Fq=3FMirja=5FK=3DC3=3DBCh?= =?us-ascii?Q?lewind=3F=3D?= message dated "Mon, 04 Sep 2017 04:42:55 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Sep 2017 19:02:54 -0700 Message-ID: <51459.1505008974@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)(39860400002)(2980300002)(199003)(189002)(105596002)(224303003)(76506005)(53416004)(53936002)(54906002)(6306002)(230783001)(97876018)(224313004)(106466001)(4743002)(189998001)(50986999)(76176999)(54356999)(97736004)(50466002)(77096006)(966005)(23676002)(69596002)(305945005)(86362001)(6392003)(7846003)(356003)(7126002)(8936002)(6916009)(81156014)(478600001)(7696004)(81166006)(2950100002)(8746002)(229853002)(5660300001)(4326008)(117636001)(55016002)(6266002)(110136004)(6246003)(68736007)(47776003)(2906002)(2810700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3525; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT046; 1:p3xTFIiJ+C0MMJ1BBNzN6vnQt3/rxM8pgcJ0m9JKibbTzLIUCaZf/tKAs3N/NpaNqpBcD87t29tixb/6aPKc9lDDLoSNI/bYkbSyhyUispN6f1e2eN0LAGefc/hh12A/ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4975ae95-5762-46b8-eb2f-08d4f7f00f03 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR05MB3525; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3525; 3:HJqU8cGNnYE1RKL/5CDsgc4u7dLpycAWWdZ6jecULgd9vzq0NGZlcGvRBsQrXJ8PWPh7AgCFOY7o08KDydJDelh3k2oFBrknpopSsE2FxlcnJXKGfgz05DGVw9L7l3Wuh92f/UGOqpGDK640eOxS0Nc1HAiG6dSxTg5qxovgyvZFItnklIxKaHNMVqLbfqRho4F/ELcagzfLG+Op7isOrPjHWWBzatf6EKtQ2D8DhCfkpyGblj/Rwpg61U2kMNMXbONEp8PeEhPr8BRtA0GtHcSfFD5QqiOA4hxcX+e8Rqmx5urFT/SzOqhdgtA6dTTdw9pWV8Bv37n+JLTM5ShFFj5BgsVPAWUmZmsxuiPBFN8=; 25:L0qqRswQ4bnLOuBJtdzWuxFV2FfwekOU7huj6iav0JLt8gY92CggmXU7/9x+Mr/YOpMYQjSPbwkAAJZ42XEG1SwPc+Fdan6eL9fZENQIEwIb+cXfqjTyGc/P07/PAXCVY4JbzGnE0C8n9S2qhoGI1JzIWrT65GcjEChndH6SoyjxBl4O4lRiuXsLwI1x9xhuMrJxpN9jK/MXnjt0nOZZKf4YLOTGMHf2os6MubrBhf71IhF1ij5dvIxlypzUK3VHtOw51FH5YrfSdnBddJLEgoPz6tpn8mh+rzX64hiSZ8S7e6wHr7mB7/3MsCwp1z2JnKryt2Lq7pIL3ULFVHcqAw== X-MS-TrafficTypeDiagnostic: CY4PR05MB3525: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3525; 31:2/92GFxsn1XtHAB9w/a7/rPjJmoDoDdzs+V62Ce9ZtszGGOJEsEe0VOj0Ub5Zhzji4D5MFYOzftQaWmzVcSAeJeU5EYtMTh/JO9XId3FiNGdd+32XeD1yF+XW6FM+afLAOaWktNeyGjmgGWc0hDsBrEH17o3HxcN0tDLVySm8WdZF7/2wbkIpb4EfZT/CmvVv4o7ZiB8Gs71LTaHk6qa7p0doFT7EMrfQOPUeoZBAaw=; 20:OKPea93YYGa2oVgDWtR5b52MvCRNmR/mSd6nNLgkxOZ3ImoNvsSpCln7175TCJ15YpbJdF9txj5aCWC4XjGpXSvbyHadEZkqmWbVES4MluheQ3BQwbrYT8vTco5IAlVuYFAoYOFnLaCgUMBs9yIbdblbL3enIs61W+xp+H33PoFsGMy/2OB6017clyMnofdQvnjL6YccKHC7ujaFa3DkD85i8sSEON6ZEIOD+f01WQrE8KBEHXGuAbmlWYwNGRyII0E2q9kTsKmimRCERlYRpKwxYrglrGcOpU9rWaedLWrGbBCd+madsrGiReWkxmqIF0UOFTRp49pkFHqOzNLDpJ5aWXq3/4jM8nmVBOLkuOlDqd3fbxgcLo9VRdDMOXpjghADb2zKldDR9Gac8j/z+GUW6XrmymCvZwPD1ZFl/uxJfPNE17VgnuKLEY1pRX4MQigMxt0x72V2szgiAsrcH+ooV5JTWnniVajCNyOSuFQhijzvoluy+jlhAXE0M+dz X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93003095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3525; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3525; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3525; 4:q/4jGA/YR5ohIAHdQoqlFyVt6GT8s+fZ37eJJLp3WRxrGs1hl0clH+t2NMgwUMzglHyob1GMoQ7F8/ydmHv+4xFVNnnPy7t+wrsHifAlJxXCjXxDa6OEa/EIz6i7XY9izgedoGX1pvwDedzknOq0C9a30MXaps2NHPapz3fi6HfMDy0S7mUWYD3emOLqwXK/4jtwxPk4AiDotGp3FATkd6Um6IwDhP2EoNAoc6B85RgH344u7PBhE3TP6ypbmueSGRTvCmRFjzBvaVUjDp4uNtoh8LeapxfxNaaCOIVUJEU= X-Forefront-PRVS: 04267075BD X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA1TUIzNTI1OzIzOlJZTFd3c3BWZm9xc0RUcWg1ODI2ckc1bWNI?= =?utf-8?B?OVdJdGZvdjRIK0htNVYxbW03elVhVStvY0VEd0VGd0x2M1JTV2JOK0tRTVow?= =?utf-8?B?YlYzbjZ4cGsyekNiMGZmZkZOYTFyU1VacGdpVDFOR0l2K2FHUDh2aWtvbVFQ?= =?utf-8?B?c012K2N4WGY1UVhZbVFwSUxuczVVYmh5OVJaRDVET2YyVGoxZG4vSFFhb1N0?= =?utf-8?B?b0xheWJnTlRKWWlsdVd0U1NUaVF6MEcyQ09NZ1AxSStlbVYvaVB4UDFXaDBJ?= =?utf-8?B?by9kVUJsUEU3Q0NDTHgzMGxPYWdXSUxKSEhtWUFMZllWZURNZi9XRFU2WU5J?= =?utf-8?B?S2RjclFZY3RIM2dCeUZmQ1Q3MHRUdGVCa0JQWngrWU1tVkVqTVVHLzFqTW5u?= =?utf-8?B?SDhoRVM1Y2orcFc3a09RQjFCK3dtRXp3NlZCRExwYUlqTE15a3VuTWkxRCtu?= =?utf-8?B?ZmI1SDlqUjU0TkVOTDNhclRUcEV6bW03WUZpZEV4WEZENW0xdnVzRUVPbkNZ?= =?utf-8?B?UjZ1TTNFdVlYVkowMWkvdjZnUnNOcjlrblRUSTVERGJjOFJMRENtd2pIQmd6?= =?utf-8?B?YmNxV2R0eU9xR1hFYnpYcFF1S1l2dmRNbGZ2dS9BSnphNTlXb3VpUGNjeGVr?= =?utf-8?B?NHowUllrb0ZhazRtVnRjNWpYb3ZDRXRCejk0VkdCeWJmVHM5ZDRKUG1ZY1NL?= =?utf-8?B?WHQvYXU4NGZTVnk5UHE0ekRnRkxRd3RSN0xhYUFscmdoL1o4R3dpWHEzcTd0?= =?utf-8?B?OENrS2NFTWlQTHhwVnFWYnJRQzJyR1VYQkZxeDg5L29UdVNaNG9yOVFUdGVD?= =?utf-8?B?N29BUmhxZzJGYjB4QS9oaWRJb2t1cWpXT0VHR3hkSTdpaW5TSVliM0ZTZk5X?= =?utf-8?B?aFB2L1lCbEg0bkRtVFZZaWgyU0E3ZTZqeS9yOVBsZUpIZzlrOG9JTlY4ZUtP?= =?utf-8?B?NWxRRmxTc0ZIdGszT3lIZVZnK1FGTW4zTGJUdGpKY1JLMzdkUU9USnpiYkFQ?= =?utf-8?B?SlREVWJFa3lycHptd1lZbVdzSlIyYjF5Z2pRQmZvL25IMmJjM0huRlVGWjd2?= =?utf-8?B?R0Q5S0Mycmk3YlZmWmJUbEw0TnVsYUNvQzBGYTNDWmpqY2t3SFFqb3dra2lz?= =?utf-8?B?WCtqZnZEVU5uWXd1Ymx3V3BFNnViOEFmQXJKMjhrajgrTER0N3VKdXliRGFo?= =?utf-8?B?RFgybzVvZFREYm5JYUdDd1h6WEMwWHFzWHlFdXhxUC83Q21wbjd4TEFjWFRw?= =?utf-8?B?Z2VVcGtzQmpaY3NYbnRObUNRYnJGcFI3OUN1VGMwbTlCRFErZlJ6R284UDFz?= =?utf-8?B?a2E4QjBFb0VRTTFQVmZyR1hTZDgzRGZhZWVkVnE5VWVYWlZtMUhVTW5HR1NN?= =?utf-8?B?eTZpVm9NQ2orVWROM1ZkM3hSSndDd1RBbkV4Sk9uWE55TUN1a3FmdW1FQ2sr?= =?utf-8?B?M0xYeGlJTHd1MUF2QTBua0NlQXBvdy9QQzVza09QNkY4Y1RYM05BNjVONVMv?= =?utf-8?B?RlR4cnllU0o2Zldyby9tVEp6MXR0OWJPTUxuTE1OeW1uVHRJeEFsek85NE9h?= =?utf-8?B?cnQxVlFLbWx3YkVIN3UyTFZFRjg3b3duOWEzMnRHZlMvelJHR3hzTU9oa3NM?= =?utf-8?B?c3U0UHhYMi81T01NbmZzZjJwQzU5cXNwMEpaZGdrcjUxSGk4bHQ2UUdBZW1u?= =?utf-8?Q?lJwQdgTbmS41rv1b0VHB5Vy/AvEaLyqMuZ+gnik?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3525; 6:L3TJ/oDXBNvTr5AJkvX2JajZatcty3IiCjwhjFJwutnBx9lh0/nj34FqHam3BzkOMY/lqsu2NPEloFsW7cDrydDmyGdsXrHy4YZYu1dcnvbhTSIWUoc6w7I9zrTaEzoyzs637lwtXIesYNcJgkPvf59Yljp1PugZauISlGk2rY1jtDu+BWHrhh+dgjz5zbVaFTrc5xBZ/PBNQTSnW0Kc4cnz3YJUIlROD7F8VqJEqder4L8+jHJk72TN330uwKlX5oRFpBOi0bba/p2Efq1U8qEPIusM7+1nhYsv/NjY3lLugPKBwgQprOfkLNqs90asZVsRwnT6YR/W0kZzN9MJsA==; 5:R/BSa5m4s4yHao9HgzK1hlYLG0HOAuq8WLX4ikUDG2Io6lPqYjtWprL4jHbyXMM5BUfUH/gRYS4PkJrnbes5o5Fp6BpLeaaTWllMiNf4XFoYocUDU4JdF+SuU2jto3BffyZgMmctoPsHJ5DGgS+MiA==; 24:tTf0jHek1atvqz78d1zyyGKczIsEWKelj5eVDmT3Oi9K9Fwy3pOa8FbhMIUElUeaoQm69AOXoXb16583+RNuNQK/FVlJWZ/Syt9OWYQ4xvo=; 7:iV348oiX3MYnR5uONx0AVYH9LIqjpH4G1yHBfUbLvLGFXjlCnK82TDfnqhWnYWlWBd9ClA734ShnUmfS2tfM2enedXZr6dDP/BBK3VZZ+0jzBle9KuQBYEchH61nlHzarVO56WgKL6E+CVhbU8hjXZX2zPtYR3NTaO85pJqLdll2FISYYBJIM9/BXFIS5mCsBnBI3jm2dtVpBGrmzvf76+0lumBgrW5IgPTnDlK850I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2017 02:02:57.9709 (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: CY4PR05MB3525 Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-curdle-ssh-modp-dh-sha2-07=3A_=28with_COMMENT=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Sep 2017 02:03:03 -0000 Mirja K=C3=BChlewind writes: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) To me this sentence does not belong in the IANA section as it is > basically the main point of the document: "This document augments the > Key Exchange Method Names in [RFC4253] and [RFC4250]." Maybe move it > to sec 3? This is a reasonable suggestion. > 2) Can you explain why the pre-5378 boilerplate is used? idnits seemed to want it to be used due to the IP for [RFC4250] and [RFC4253] which this document extends. I will change it from pre5378Trust200902 to trust200902 if there are no objections to that update. -- Mark From nobody Mon Sep 11 08:50:37 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4202133147; Mon, 11 Sep 2017 08:50:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150514502563.9757.15916793470185466485@ietfa.amsl.com> Date: Mon, 11 Sep 2017 08:50:25 -0700 Archived-At: Subject: [Curdle] Genart telechat review of draft-ietf-curdle-ssh-ext-info-12 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, 11 Sep 2017 15:50:26 -0000 Reviewer: Matthew Miller Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-curdle-ssh-ext-info-12 Reviewer: Matthew Miller Review Date: 2017-09-11 IETF LC End Date: 2017-07-30 IESG Telechat date: 2017-09-14 Summary: This document is ready to be published as Standards Track. All of my concerned from revision -10 are addressed in this revision (-12). Major issues: NONE Minor issues: NONE Nits/editorial comments: NONE From nobody Mon Sep 11 12:45:12 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 E196F132339; Mon, 11 Sep 2017 12:45:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org, joelja@bogus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150515910592.9770.2709380152256609564.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 12:45:05 -0700 Archived-At: Subject: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-des-des-des-die-die-die-04: (with COMMENT) 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, 11 Sep 2017 19:45:06 -0000 Warren Kumari has entered the following ballot position for draft-ietf-curdle-des-des-des-die-die-die-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Joel for his OpsDir review. I have a few comments / readability suggestions: 1: Section 5.1. Statistical Biases "These attacks seem to rely on repeated encryptions of thousands of copies of the same plaintext; " -- for a document which deprecates rc4-hmac the "seem to rely on" feels very weak. I'd suggest s/seem// or "At least some of these attacks rely on..." or similar. 2: Section 6. 3DES Weakness "Additionally, the 3DES encryption types were never implemented in all Kerberos implementations..." s/never/not/ 3: Section 6.3. Interoperability "The triple-DES encryption types were implemented by MIT Kerberos early in its development (ca. 1999) and present in the 1.2 release, but encryption types 17 and 18 (AES) were implemented by 2003 and present in the 1.3 release." I'm a bit confused by the "but" - should this be "and"? Otherwise it sounds like it it trying to contrast something. From nobody Tue Sep 12 11:37:27 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 77522126B6D; Tue, 12 Sep 2017 11:37:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524144548.17894.106479337730195058.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 11:37:25 -0700 Archived-At: Subject: [Curdle] Spencer Dawkins' Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) 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, 12 Sep 2017 18:37:25 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a readable document. It was a pleasure to review. I have a few comments, but "Spencer doesn't know much about SSH" might be a fine response for most of them ;-) In this text, Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect. why would a party that doen't support this extention disconnect? I ask, because this looks like a MUST requirement that might apply to an implementation that doesn't support this extension. If that's normal SSH behavior, that's all I need to know :-) In this text, If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message: - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. If this extension takes effect, the client MUST send the following message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: byte SSH_MSG_NEWCOMPRESS (value 8) The purpose of NEWCOMPRESS is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's USERAUTH_SUCCESS. I THINK the point is that the client's SSH_MSG_NEWCOMPRESS is sent after SSH_MSG_USERAUTH_SUCCESS, before the client sends its first SSH message that's compressed using the newly negotiated compression algorithm, but "MUST send ... shortly after receiving SSH_MSG_USERAUTH_SUCCESS" doesn't help me figure that out - I'm mostly guessing, based on "the renegotiated compression algorithm is activated for the very next SSH message after the trigger message". But (1) if I got that wrong, it's at least unclear for TSV ADs, and (2) if I got that right, I'm not understanding what "shortly after receiving" the trigger message is saying - for example, I wondered if there's a timer involved, so that if a client doesn't have messages to send, it should still send SSH_MSG_NEWCOMPRESS, or the server will think something's wrong. In this text, This extension MAY be sent by the client as follows: string "elevation" string choice of: "y" | "n" | "d" A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. The server MAY disconnect if it receives a different extension value. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent. The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator user's logon session is associated with two security contexts: one limited, and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see also [WINADMIN] and [WINTOKEN]. If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request: byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply = false boolean elevation performed I would find this easier to understand, if the paragraph defining the terms was the first paragraph in the section, and then the description of the extension (which uses the term "elevation") followed. It's not bad, the way it is, but the reader has to read past the description to find out what the definition means. The security considerations are brief and refer to overarching security considerations, which I understand because this is an extension, but Security considerations are discussed throughout this document. This document updates the SSH protocol as defined in [RFC4251] and related documents. The security considerations of [RFC4251] apply. doesn't say anything about new security considerations to think about, when you add support for elevation, which seems like it would be a new attack surface, but I could imagine that adding elevation is the first step toward fewer SSH server implementations that always run with administrative rights just in case they ever need to use them, so the attack surface is getting smaller? ... And now I see that Mirja also asked about elevation, and your answer to her was pretty much what I had guessed. Maybe it's worth summarizing your answer in section 3.4. From nobody Tue Sep 12 11:48: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 C3BF11330B5; Tue, 12 Sep 2017 11:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524208179.17923.6018833793093966718.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 11:48:01 -0700 Archived-At: Subject: [Curdle] Spencer Dawkins' No Objection on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) 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, 12 Sep 2017 18:48:02 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So, I see that the recommendations are mostly SHOULDs. Is this, perhaps, for backward compatibility with SSH implementations that don't implement this specification? This isn't remotely something I'm smart about, but I do wonder about bid-down attacks to, say, 1024. Is that possible? From nobody Tue Sep 12 11:58:50 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 C325A1330B8; Tue, 12 Sep 2017 11:58:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524271479.17914.6597825899861851227.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 11:58:34 -0700 Archived-At: Subject: [Curdle] Spencer Dawkins' No Objection on draft-ietf-curdle-des-des-des-die-die-die-04: (with COMMENT) 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, 12 Sep 2017 18:58:35 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-curdle-des-des-des-die-die-die-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja's points about Obsoletes vs. Historic, and I didn't think we required a status change document for *all* move-to-Historic status changes, but https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html says that we do. On the brighter side, that may be the best draft filename I've seen as an AD ... From nobody Tue Sep 12 13:00:26 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 26D071330C3; Tue, 12 Sep 2017 13:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524641915.17931.336171474713370061.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 13:00:19 -0700 Archived-At: Subject: [Curdle] Alia Atlas' No Objection on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) 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, 12 Sep 2017 20:00:19 -0000 Alia Atlas has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The IESG write-up is for the wrong draft - but it was easy enough to read the detailed shepherd's report. Thanks for a clear and well-written draft. From nobody Tue Sep 12 13:05:23 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34D132F2F; Tue, 12 Sep 2017 13:05:17 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524671702.17967.13250532902174791446@ietfa.amsl.com> Date: Tue, 12 Sep 2017 13:05:17 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-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: Tue, 12 Sep 2017 20:05:17 -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 WG of the IETF. Title : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-06.txt Pages : 17 Date : 2017-09-12 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-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 Tue Sep 12 13:05:41 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 87AB21330D6; Tue, 12 Sep 2017 13:05:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524672952.18023.11139350789025104795@ietfa.amsl.com> Date: Tue, 12 Sep 2017 13:05:29 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-schaad-curdle-oid-registry-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:05:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF. Title : IANA Registration for Donated Symantec Website Security Object Identifier Range Authors : Jim Schaad Rick Andrews Filename : draft-schaad-curdle-oid-registry-02.txt Pages : 5 Date : 2017-09-12 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-02 https://datatracker.ietf.org/doc/html/draft-schaad-curdle-oid-registry-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-schaad-curdle-oid-registry-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 12 13:06:51 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 7968B132F2F; Tue, 12 Sep 2017 13:06:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524680948.17880.11498685853024501328.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 13:06:49 -0700 Archived-At: Subject: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) 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, 12 Sep 2017 20:06:49 -0000 Adam Roach has entered the following ballot position for draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1, paragraph 2: New MODP groups are being introduced starting with the MODP 3072-bit group 15 all use SHA512 as the hash algorithm. I can't parse this. Should there be a sentence break between "15" and "all"? I was surprised to find section 4 here; in part because it isn't related to the addition of new algorithms, but mostly because it's not mentioned in the abstract or the introduction. Please add mention of this erratum correction to both sections. I'm pretty sure RFC6234 needs to be normative. From nobody Tue Sep 12 14:22: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 0A43813314B for ; Tue, 12 Sep 2017 14:22:15 -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=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 QOKSfeAH04nd for ; Tue, 12 Sep 2017 14:22:13 -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 07ED4133149 for ; Tue, 12 Sep 2017 14:22:12 -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=1505251287; h=from:subject:to:date:message-id; bh=D6hix0F7I+77EA7LCTyROpG7eCNw72NXid2FepHu7gc=; b=AJJNmUnU/I20SKMDL2ctmXC72NNibrRppaSeF2/LEs64CuHIe0nolqKAoZptj2N58KTIjc8Y1Hw KMd8b8Vwj/Q7x5zFy7F3uY2CoDlG35U7uMdXE9t+IHvahzyPJq8jp6G33GVdXny2Cx/mz60hW6UtE 3DBZVcfEF+nlI0cetBOywdoRMR//I/53mRpqbv+WwRDKsxG/HqR9bhFhn2v2yjYlKAyEdx6efsN3h GCut4C8HDt+D1ZWEyoURw2uLAPBj5Cna7KoGqWU4YWVddiVg0W3vTa9eyP+Zn/l/HIsSWLLYPgRxu I7EerFuDUfFP/MosBy07dJzO1HFZj/Z7hoHw== 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, 12 Sep 2017 14:21:27 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 14:21:27 -0700 From: Jim Schaad To: 'Curdle' References: <150524671702.17967.13250532902174791446@ietfa.amsl.com> In-Reply-To: <150524671702.17967.13250532902174791446@ietfa.amsl.com> Date: Tue, 12 Sep 2017 14:22:02 -0700 Message-ID: <017f01d32c0d$2f528310$8df78930$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF+W1N+Kh0DbSwgAEE+5vWEsz0Hz6NbY5UQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Curdle] FW: I-D Action: draft-ietf-curdle-pkix-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: Tue, 12 Sep 2017 21:22:15 -0000 This version of the document should address all of the AD review comments. Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, September 12, 2017 1:05 PM To: i-d-announce@ietf.org Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-06.txt 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 WG of the IETF. Title : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-06.txt Pages : 17 Date : 2017-09-12 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-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/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Sep 12 14:23: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 6809E13314A for ; Tue, 12 Sep 2017 14:23:21 -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=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 9zp-ILVXlNSl for ; Tue, 12 Sep 2017 14:23:20 -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 2E735133149 for ; Tue, 12 Sep 2017 14:23:20 -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=1505251356; h=from:subject:to:date:message-id; bh=+QfE7AxbKlhnz9Dm/RE5aYlcvqUoEMp9NirCjdE2JYI=; b=Mpn7W/idWIAKW+sthVBXCAtVe6SUcjioACk+DIMM5YjLYYJedWTTNwVte12Fj08PjfHkqxr9zqG W9mB4j+iFd5ZWD9k5wcMc5fu+uZNB3+lYZfx9ga/yM+Ju5z1by4D9+bJ6naXVgd60G/hUnJHK2WTn ZBFH9oqkE+ioVqbOu1tqblLl4K/Rnxc8O0MYPVXxEBthYeDdURx+cBpEHfo7jkKE8odgsYR4tfgbp LG1nyLGIUZXOipiwzRt4ITOyPgP7Wl+NnsLjwjP/pYf24B/eWLAEQEuRk0QlQ8rY0OwBFuGDGi+/F VdIEaUeVGFDC+vwEdSRwJeGlBip4PijMXg6A== 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, 12 Sep 2017 14:22:36 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 14:22:35 -0700 From: Jim Schaad To: References: <150524672952.18023.11139350789025104795@ietfa.amsl.com> In-Reply-To: <150524672952.18023.11139350789025104795@ietfa.amsl.com> Date: Tue, 12 Sep 2017 14:23:12 -0700 Message-ID: <018001d32c0d$58509770$08f1c650$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFW8hyRmd2gC+kIUXoS4ZNmbLIFBaOqNk0w X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] I-D Action: draft-schaad-curdle-oid-registry-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 21:23:21 -0000 This version of the document addressed some IANA concern issues. It should be ready to move to AD review now. Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, September 12, 2017 1:05 PM > To: i-d-announce@ietf.org > Cc: curdle@ietf.org > Subject: [Curdle] I-D Action: draft-schaad-curdle-oid-registry-02.txt > > > 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 WG of the IETF. > > Title : IANA Registration for Donated Symantec Website Security > Object Identifier Range > Authors : Jim Schaad > Rick Andrews > Filename : draft-schaad-curdle-oid-registry-02.txt > Pages : 5 > Date : 2017-09-12 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-02 > https://datatracker.ietf.org/doc/html/draft-schaad-curdle-oid-registry-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-schaad-curdle-oid-registry-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Sep 12 14:53: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 6D1AA13247A; Tue, 12 Sep 2017 14:53:03 -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_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 nifuWygiwFYe; Tue, 12 Sep 2017 14:53:01 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53947124205; Tue, 12 Sep 2017 14:53:01 -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=tMiJrr8OqSDVPwM2c39RpMIhnyq/nx6Vt/RCEOA8PFo=; b=FdHN1QRW7xUjO68e8FOR6uFV8k3drIEgy7OerZ8Fj8/cEK9D3lCaoHcr7PsPbYHb61ZtcxbArVlRVpRWbbBUdo40A9gynlIrFwx3/ULgq07IZxG2nT1jdd9xdMT7TQvryymaGYNr4jip9B4L5NyUOXE4/28OqvAZKtzSOGaEJWY= Received: from CY1PR05CA0034.namprd05.prod.outlook.com (10.166.186.172) by CY1PR0501MB2076.namprd05.prod.outlook.com (10.164.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 21:52:59 +0000 Received: from CO1NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::206) by CY1PR05CA0034.outlook.office365.com (2a01:111:e400:c5a4::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4 via Frontend Transport; Tue, 12 Sep 2017 21:52:59 +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 CO1NAM05FT034.mail.protection.outlook.com (10.152.96.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.35.14 via Frontend Transport; Tue, 12 Sep 2017 21:52:59 +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, 12 Sep 2017 14:51:45 -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 v8CLpj5b004704; Tue, 12 Sep 2017 14:51:45 -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 818AC1141B; Tue, 12 Sep 2017 14:51:44 -0700 (PDT) To: Adam Roach CC: The IESG , , , , In-Reply-To: <150524680948.17880.11498685853024501328.idtracker@ietfa.amsl.com> References: <150524680948.17880.11498685853024501328.idtracker@ietfa.amsl.com> Comments: In-reply-to: Adam Roach message dated "Tue, 12 Sep 2017 13:06:49 -0700." From: "Mark D. Baushke" Date: Tue, 12 Sep 2017 14:51:44 -0700 Message-ID: <82639.1505253104@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)(346002)(366002)(376002)(2980300002)(189002)(199003)(6916009)(7846003)(2950100002)(5660300001)(97876018)(106466001)(77096006)(7126002)(7696004)(69596002)(117636001)(54356999)(2810700001)(105596002)(6392003)(316002)(230783001)(50986999)(76176999)(53416004)(2906002)(76506005)(478600001)(55016002)(6246003)(50466002)(305945005)(54906002)(53936002)(68736007)(81156014)(8936002)(81166006)(86362001)(4743002)(356003)(97736004)(8676002)(47776003)(189998001)(110136004)(229853002)(4326008)(5003940100001)(6266002)(48376002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2076; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT034; 1:lJoXeiFGiSuRdj2X8omXq0jdMo0rELek4ijCZGSrf7mIr/suAYEymea2xQDFUrWc864MBnk5wvH2Z75Bw9ZhU6Dfb/OCDkLf4DPkPj3QRxAsBgIs4IAqJsIU0/kMzObb X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 01a611ec-b4aa-4eff-c240-08d4fa28a248 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB2076; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 3:MhWAfxe4RZ5VeP6/2pJazxU8KpsBGmSKhTUNW/PeCY3FmPCSa/CH5g8twj00kXcejvsvujZEoGe1N7wrw1gA2ACqe8yG/4sBnyznC22cKSQUjQKOniFxVI14ujsjKfUveIslQjamSCTn158MWJeKGqm3GCJiMOB4H+LePZ6v8fykM3XKkjP2PnUu5fHRyIbJdH8vm2X5hiJOG/MITrckcp3IPySDmBqE5fy/HTO9o082ZCFcXDkBrEs0Esf1cAaDcsvvzuevU6WucFZhUaUukphmgS/gg0dVGSWVTv8/a8/uFSR8NPMMjRiBB6PU60E081HtUK1bIkOUu8R+PwZkHQlojeoHHSt5CkwprDs5I5E=; 25:l0/d0bNjtc4g6fZnYiwMyHd7LcOfB7QcrfWXYgeU4mpd9AnsEr89LOtuGzFaCXWmkrKhDa9RgZ9VS9QtskFf4GYk3NgBCECAK13qsMaZi2bnvoymJJBjIBS+zcy2/jXac+7M1TMjFVFQcQI7WSaOkMrbNFqIf2FGlRX11+xDsw0JvgCdsA10ATcOwseiYLtAvHVC7ALANjGiH7j8eFjEVj7yuz/j81rZk+TrpkfouOhTT4wqZtgAmd1XmAS1et2GnQ/WZ0wlWel1/mKEGqTtY9pYvInABUs7fOXKvDJC//8xSJQP41zG/oqhr+TyvQLRRCQMBTnN7ko1BQ+SdUNvpw== X-MS-TrafficTypeDiagnostic: CY1PR0501MB2076: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 31:bpgnPgZahiVgWRggRx3+oqa5Fkl8snjAIZoxdDtuB4O98i60GEeG9vIc2Zk2hEvoNDqXpz611B4PI2ZWzYaO1gqmUsWlRZpzBZnvAhUZUbXhYHu5bmpTmN5kviu+46gk3ARGNeo6/5ffkeW/nLpuGEWehvhQC9uI9vZTGn4IG5lCFmzPhspqUt8h3cpSYnQkAS6VPj9pc8A6rM7X414aqLFXCXkfIgnLhQweZdD0WoA=; 20:Q+bVA5PMWL23r7skcHz+JiJDrmMhX47ORpsl4WW5NJACqqPFeIYgOK+xu7Z6IetEpINDEUF4ZW86qlVdxeF37a2m8jPQqLXTFxKKNgqdqh0SWQozlse0VFMEu2+6QYwKhSozzpgZ/5fOYPWNedjyIZ0z3HybPnn4YLoxc3l04Aquc0yTryjaep3hcd1Zscv97mOrl+zQjgIEFZJlMVA96Ww3kSrFZMtgepKSEj5BfOFxkoSpcugQrD/nE59RGiccLGa1PHvwUWcpmHuePNaU9gv2ft+OK2m8/0JwSFfV2OON1f5E6tvFOAwwSpVf3G5saN7x7vD0hLG57I9xBtlXfehLUdxL/VdLh7MHkz2dd8E90UnVAX23WcvXlCaiQy4jr0PM0Swkr+usC4FH65Mfexb0uCwy1UwFanMG6sSN9JcYrLByFIZHZsI0wNQSS8KlNbWgGbMpm3+HmFlMSw0NEsn6fTTBzWLSGx0oYx/oH2JSanvBatP6xDrB6kPjovBA X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93003095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB2076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB2076; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 4:zRAkqDL9TGLzVn7B1acR8mw2aZeM1ikylmHISJoydqWRLbPXFzGhawHfoORi9RmygiUnCWmTDWesVQnfupOcz5L0U9Ryrz2szM7kFc15eWfW2bo2XDXMtV9K9PuUjodqz9i2GuwWHDX2BB+nYEVb5Se/HJIteLNYmf7ELEud9MMBnsgpZOETISg/l8zI/diuQTJIUC0vS3TBEr/WAgIrVe6EAR4xO1qJjKKkI3uN2UeIUFCD6g7JkNOxnQEoCKGY X-Forefront-PRVS: 042857DBB5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB2076; 23:Yhngb0WfgVg0Vc1DwTfmqTa6BauuEHsfgxqWeRX?= =?us-ascii?Q?mk9oSN/rCKPIxrv0C8NQuiFmlsc9Otwu/sW+bx6+v82kTHkqgzpyXitc7Rwy?= =?us-ascii?Q?vJBPIT2bK+4nVBmwMyJfEqpfvPiPl1ZImnyOmI8MwqLCAls6grbv4Mlhf2Cl?= =?us-ascii?Q?dn/zhtM0sBdg/mjYfuBwilugLolBfOo9BTJuRejiWj8mHXlxMMTHD0BwA8i1?= =?us-ascii?Q?t7S6p90eI/3eF5VrSMQa/rINEFfwTTiGT/TyoSSV5IbmzYlgakOF0C4FPySr?= =?us-ascii?Q?egT+K00qC2VIAqkX2sfZZct8qtu8FVwlbAuzYVnB/IM9fpnObnd4rnftlwpN?= =?us-ascii?Q?k9y3p2MIky9hzTocRqEj3Ca/V412PXQgPCco1+1yCI5eXYkgyZQNkuwGeFlg?= =?us-ascii?Q?NrabGs0FI6oebq3Yk+Sv3zb7MNZdw5PeT6wTIWgzuq6bplQltAbkYZvvmHWq?= =?us-ascii?Q?0o6TFnlIdHv5IgJINcgbEPQeQpCskVsyMUBb5rXvA3ME8N+pJOWteaL0L5Ie?= =?us-ascii?Q?cN/LW+Fm/6rDM1KerCJtSkhIe1tv4wkztlxar3ISmYs/WpaakPWmywbpqK4Y?= =?us-ascii?Q?xcGK0BkO0NZto36KoGHW9GUkJq8DxMiEbsowebBlkI57o2tVWFjRKZpudOLt?= =?us-ascii?Q?KUP7mN2Gv+DCnpuY6t8J3G9qQ8KRV/LCGddrIXbGUg+1m6RD+nspxGar5DYk?= =?us-ascii?Q?8xlQrquuo3LNRZEuIwmjkCLQgaSXHY4T3hAGOLuT0l+BOzyTAvFIZKjInnKF?= =?us-ascii?Q?iOosaRkix5QIgIARK3Q2lkSoK1aEbjZT16vTKtWUdE3zHkUlP+3NjSDKtt26?= =?us-ascii?Q?36UfrgJA3a9y0MlzijRUEcao3u2iOUwSPLRmIg4oNvp55DzWyndXPlK1BSoZ?= =?us-ascii?Q?53LbjyNfAfE2QxWItteRnSBRY2Aj27QQZaAGngyVNfQD/D5jWy3YpMJRNor3?= =?us-ascii?Q?UPPq/9uzDN8F0Mg9Z+7FRnFg0Pqqf82hbnsg8yTa2hvXhjLd+3WrAamWWwiO?= =?us-ascii?Q?+9O53d5GV7v3jcvp1rDo2N1BUojVthIxWvlwYTAhOp5DaCeZE8kJTf1VhNKO?= =?us-ascii?Q?4hRXkb8CFunaQjR7KsBdEZ6atvWg982OTu/jRESN1mh+qayCnx3l7R9MIxZr?= =?us-ascii?Q?O+EUH1xi0/qm+wFih6GzT9MfKCrdd+yzA/7SjxAFasDGvtkWgDpbIzwAmRhE?= =?us-ascii?Q?kbYctVw2/G/8QSR5rFcbD2ZmXlbPoEXc5SuCdsMsw2MXmUWhh3L+zQ65z1sT?= =?us-ascii?Q?JQ8Y9lUb7/H9PG66RbsLE7HyQq5jrJtJAEVRktyA8gsMLBjN9uj4+nyizczg?= =?us-ascii?Q?LZA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 6:HxyloQ7twMbsJgCU9MciprTJ6dk/E4qBx3ICvC2AwI0nd8sN36xC4AUq5OEbGSqhrspSGhhsQbjeuqmPD4hd75UhVHYKcU8Vshvg6jD9DhG7G62o8fCbOJ8uCY9ohbSHGBqEZEGj6JCizs7BNdJzFCbpWVv6UO5e1XotWfxMLJVcmfgYNXOKl/Fvu7Qd0su8ZbEHOCxJdfHYHcs1MDe0RnqXgzHCgEaIgu7xAUdlldpk3lj9bkJUybgjv5tC/ZNPqPXeBuIsWfCccO5Z18NLKPnJEeVYAcLltTuxpxWf1TS4FoLpP8zTGRAWiY2pr1mJyjkldqg4RIRHj2Pyr6BgYw==; 5:rkJmKkkFDAcxPOM1BhnaKhLD/MIu5Z++D2hHvOQ50NJUwwBBUox/lMfpK0abkYgRT+ffwjamzh9TQ2VAzQM9xqTZLuX47N+jqDZz4Ea4gDZ+io0yywrx2/EcGBAuDFppsdyqvgshm+CNpOjMzD0G3A==; 24:qndZ4jsG/mrOkA5ASamqKYr/T5IMOcE4jFo9lQECxMfjX/IUlDGXbQiYURl+26IUMHidVi039EhbYWHDFalxvej+GCFAa2iuGLr5ChI8n5I=; 7:zCKZzpdFMUcbiX5EWXcTtzKQipM9Ev3BpZUH/cpr0wfNPTVW9j7lCzq4PMqwbuOKIHniIabx+Ai4/lfUg6I47loTYvBh4Z1D6OJgR29pReESbxLEcJIs90PXp83+GzHeELivHQdkIlfwIqGl33PcQ80Ty4rCrKaTgSffEHXpb0sMGFK+awsDaUl2580rtuM/N/6vl3GDjF2ZtaIPHTpH8wOhYiip35c/tB2h2oBDhRI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2017 21:52:59.1739 (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: CY1PR0501MB2076 Archived-At: Subject: Re: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Sep 2017 21:53:03 -0000 Adam Roach writes: > Section 1, paragraph 2: > > New MODP groups are being > introduced starting with the MODP 3072-bit group 15 all use SHA512 as > the hash algorithm. > > I can't parse this. Should there be a sentence break between "15" and "all"? Yes. There should be a period after 15 and 'all' should be 'All' > I was surprised to find section 4 here; in part because it isn't > related to the addition of new algorithms, but mostly because it's not > mentioned in the abstract or the introduction. Please add mention of > this erratum correction to both sections. Thank you. I will change 'This document updates RFC 4253.' to 'This document updates RFC 4253 including an errata for checking the Peer's DH Public Key.' in the abstract. I then added Section 3 of the [RFC4253] contains a small errata for checking the Peer's DH Public key. Section 4 of this document provides the correction. as a new paragraph under the Overview and Rationale. > I'm pretty sure RFC6234 needs to be normative. Okay, that is an easy change to make. -- Mark From nobody Tue Sep 12 15:24: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 BFFDB12421A; Tue, 12 Sep 2017 15:23:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150525503378.30416.5679611796140295482.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 15:23:53 -0700 Archived-At: Subject: [Curdle] Adam Roach's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) 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, 12 Sep 2017 22:23:54 -0000 Adam Roach has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am concerned that the syntax of "delay-compression" is not specified with enough detail to ensure compatible interoperation. I may have missed something in the protocols this document relies upon; but if I haven't, I think this needs additional specification. The current definition for "delay-compression" is: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client In reading through this document (and skimming RFC4251), I don't see anything that indicates the on-the-wire encoding for "string containing multiple name-lists." I suspect that the intention is something like [string-length][list-length]value[list-length]value; however, that requires making a number of unstated assumptions, and I doubt that all implementors will make the same assumptions. To be clear, what I mean by my formulation above would result in the value field of client_to_server="foo,bar" and server_to_client="bar,baz" being encoded as: 00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61 7a If this is the intention, please be explicit (and, ideally, provide an example). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.4: (*) The message MUST be sent at this point for the following reasons: It's not clear how this normative requirement interacts with this MAY: The second opportunity is just before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send EXT_INFO at the second opportunity, whether or not it sent it at the first. One seems to merely allow it, while the other seems to demand it. Could you add some text that clarifies this apparent contradiction? From nobody Tue Sep 12 15:52: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 16DAE13316E; Tue, 12 Sep 2017 15:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2BfZC5j9yIG; Tue, 12 Sep 2017 15:52:21 -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 187B1132969; Tue, 12 Sep 2017 15:52:17 -0700 (PDT) X-AuditID: 12074424-f97ff70000001016-94-59b8651f4668 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 84.E3.04118.F1568B95; Tue, 12 Sep 2017 18:52:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v8CMqEaK026459; Tue, 12 Sep 2017 18:52:15 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8CMq80u006019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Sep 2017 18:52:11 -0400 Date: Tue, 12 Sep 2017 17:52:08 -0500 From: Benjamin Kaduk To: Warren Kumari Cc: The IESG , draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, joelja@bogus.com Message-ID: <20170912225208.GE96685@kduck.kaduk.org> References: <150515910592.9770.2709380152256609564.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150515910592.9770.2709380152256609564.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT0ZVP3RFpsG6vjcXMng3MFlsXzmK2 mDJ9D5vF064jTBYz/kxktnh1ag2jxeFjl5kc2D3OHlnA6PHr61U2jyVLfjJ53L7xhz2AJYrL JiU1J7MstUjfLoEr48KiRraCpbwVsyaeYm5gfMLVxcjJISFgInHyxSOmLkYuDiGBxUwSpxd9 YYZwNjJKPOxrYIRwrjJJTPz+gRWkhUVAVeLtp1lgNpuAikRD92VmEFsEKN64YD87SAOzwBVG icVvWthBEsIC2RLbd29hAbF5gfad33ecCcQWEvCReHN8AhtEXFDi5MwnYDXMAloSN/69BKrh ALKlJZb/4wAJcwr4SnzYeQysVVRAWWLevlVsExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5 xanJusXJiXl5qUW65nq5mSV6qSmlmxjB4e6isoOxu8f7EKMAB6MSD++KO9sjhVgTy4orcw8x SnIwKYnyZivuiBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwusUA5TjTUmsrEotyodJSXOwKInz ims0RggJpCeWpGanphakFsFkZTg4lCR4zyQDNQoWpaanVqRl5pQgpJk4OEGG8wANdwGp4S0u SMwtzkyHyJ9iVJQS560ASQiAJDJK8+B6QelIInt/zStGcaBXhHnFUoCqeICpDK77FdBgJqDB PJe2gAwuSURISTUwlrixe8pcPpGxhrWw4POKzhLh6WKn4m3WCizZa+5b3lIyJ3bxqmCFb3rM GZdM9O8ftew40PH4qZPpSwebp8pNEw//Yl1UVbCtmc/MnsO90P53hy6ntq6Iku77V0bdHTIn TK9lc9UbMEf8vH+xSfaL4kuZC1mJdmcX1/+JMqkJvPfvW89N5zIlluKMREMt5qLiRAD17FRy IgMAAA== Archived-At: Subject: Re: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-des-des-des-die-die-die-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Sep 2017 22:52:23 -0000 Hi Warren, On Mon, Sep 11, 2017 at 12:45:05PM -0700, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-curdle-des-des-des-die-die-die-04: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Joel for his OpsDir review. > > I have a few comments / readability suggestions: > 1: Section 5.1. Statistical Biases > "These attacks seem to rely on repeated encryptions of thousands of copies of > the same plaintext; " -- for a document which deprecates rc4-hmac the "seem to > rely on" feels very weak. I'd suggest s/seem// or "At least some of these > attacks rely on..." or similar. Sure, accepted. > 2: Section 6. 3DES Weakness > "Additionally, the 3DES encryption types were never implemented in all Kerberos > implementations..." s/never/not/ Accepted. > 3: Section 6.3. Interoperability > "The triple-DES encryption types were implemented by MIT Kerberos > early in its development (ca. 1999) and present in the 1.2 release, > but encryption types 17 and 18 (AES) were implemented by 2003 and > present in the 1.3 release." > I'm a bit confused by the "but" - should this be "and"? Otherwise it sounds > like it it trying to contrast something. The intent is more along the lines of "but they were superseded when", so I'll make that change in my working copy. Thanks for the suggestions! -Ben From nobody Tue Sep 12 22:34: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 BA79813306C; Tue, 12 Sep 2017 22:34:13 -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 KsA9QT5YM4H1; Tue, 12 Sep 2017 22:34:11 -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 1516D129B7A; Tue, 12 Sep 2017 22:34:10 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id d17so31331420lfe.2; Tue, 12 Sep 2017 22:34:10 -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=t7UZhdbe5Pn3fGwwf7TjBqeXxzCU0dV+rnpI0rxtFdc=; b=UBd/uxzfDL2zGsahRKaPyC8K7mFmpjMZIxbCbKd0ntoyI3ZXL6a7lxBW4csJuZZuZN AoqgJ5m9kSAIW8+x5yPvv02cGY5IAFjAGfeey50IgtRvPd6uA/texAEW8Bz/gENWVGi1 zaCCcO2R6zJbhrT5uBnWD2JsKagzfCJdct0YkyqFabmMFf/TWWeNQ+X2yyV2M9RZl1BK ysYrUH3LDtG+ws7HD0sZXGS6gNQXBxdOkIr67p1oo9KmUOjXysZjW6BYli4N8K1KEQ2E OlA1cvpqQqApsSMu11234zRjdc/rBrHUHpTvn3slC24uL6NDhYbKu89G0zO6K7nEOchi Bgfg== 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=t7UZhdbe5Pn3fGwwf7TjBqeXxzCU0dV+rnpI0rxtFdc=; b=SI9YZzF3FXoDoib8VECpXLdf9Il+VDgc3t88TevkF4EpEuUFOWxEZTPd7DyquHfk+t UeJpKz5XD54/NB4EIkXlrRmZY001opLcy6Pc1680tOXqfEBP4obzPhAJbOiKVG/BZUuq SW+Hfu2OAq1+yZP/fBmJgQZMwUl5S22tcsc2ALCsSsLj8Bn0BuC8tfPjDCuZxmWPPTS0 LheB/OxZGr2+VhEkDrKS6tFXTuq7iSxkzwqFhnXRc9YxH4po+yKrYgyMKIGR8fHchcm/ ClqblH2SmiLi1GbV6Doe8QuGidHcFa5CAnTPGn/JBmIuO6ljy/9DPXdOpXUMa8kalq/d ktJg== X-Gm-Message-State: AHPjjUil3F3bag5zMzDqsUkdSsvW7FkJc/HpBgU963kC5jwygDj3YG+I VibyLT7SlRQyE3SIk8wywoGZx6ZWYCTO42muIk0= X-Google-Smtp-Source: AOwi7QDbt7e+qhXV2BJMvizQ34Lu5IfPljk9Dc6VMeCiC0gqiJWHhYxaC2QRaePP0lByLD6a8eiFNJHFtB0EuvUngZw= X-Received: by 10.25.18.195 with SMTP id 64mr5283934lfs.60.1505280848939; Tue, 12 Sep 2017 22:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Tue, 12 Sep 2017 22:34:08 -0700 (PDT) In-Reply-To: <150525503378.30416.5679611796140295482.idtracker@ietfa.amsl.com> References: <150525503378.30416.5679611796140295482.idtracker@ietfa.amsl.com> From: denis bider Date: Tue, 12 Sep 2017 23:34:08 -0600 Message-ID: To: Adam Roach Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a113fb8f849cfdd05590b8230" Archived-At: Subject: Re: [Curdle] Adam Roach's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 05:34:14 -0000 --001a113fb8f849cfdd05590b8230 Content-Type: text/plain; charset="UTF-8" Comment 1: Good point. Example is useful. Will add example. Comment 2: This is meant along the lines of "*If* the server sends a second EXT_INFO, it MUST be sent at this point". Will look into clarifying the language. On Tue, Sep 12, 2017 at 4:23 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am concerned that the syntax of "delay-compression" is not specified with > enough detail to ensure compatible interoperation. I may have missed > something > in the protocols this document relies upon; but if I haven't, I think this > needs additional specification. > > The current definition for "delay-compression" is: > > string "delay-compression" > string: > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > > In reading through this document (and skimming RFC4251), I don't see > anything > that indicates the on-the-wire encoding for "string containing multiple > name-lists." I suspect that the intention is something like > [string-length][list-length]value[list-length]value; however, that > requires > making a number of unstated assumptions, and I doubt that all implementors > will > make the same assumptions. > > To be clear, what I mean by my formulation above would result in the value > field of client_to_server="foo,bar" and server_to_client="bar,baz" being > encoded as: > > 00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61 > 7a > > If this is the intention, please be explicit (and, ideally, provide an > example). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2.4: > > (*) The message MUST be sent at this point for the following reasons: > > It's not clear how this normative requirement interacts with this MAY: > > The second opportunity is just > before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The > server MAY send EXT_INFO at the second opportunity, whether or not it > sent it at the first. > > One seems to merely allow it, while the other seems to demand it. Could > you add > some text that clarifies this apparent contradiction? > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113fb8f849cfdd05590b8230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comment 1: Good point. Example is useful. Will add example= .

Comment 2: This is meant along the lines of "I= f the server sends a second EXT_INFO, it MUST be sent at this point&quo= t;. Will look into clarifying the language.

On Tue, Sep 12, 2017 at 4:23 PM, Adam= Roach <adam@nostrum.com> wrote:
Adam Roach has entered the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I am concerned that the syntax of "delay-compression" is not spec= ified with
enough detail to ensure compatible interoperation. I may have missed someth= ing
in the protocols this document relies upon; but if I haven't, I think t= his
needs additional specification.

The current definition for "delay-compression" is:

=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-compressi= on"
=C2=A0 =C2=A0 string:
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_client_<= wbr>to_server
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_server_<= wbr>to_client

In reading through this document (and skimming RFC4251), I don't see an= ything
that indicates the on-the-wire encoding for "string containing multipl= e
name-lists." I suspect that the intention is something like
[string-length][list-length]value[list-length]value; however, that req= uires
making a number of unstated assumptions, and I doubt that all implementors = will
make the same assumptions.

To be clear, what I mean by my formulation above would result in the value<= br> field of client_to_server=3D"foo,bar" and server_to_client=3D&quo= t;bar,baz" being
encoded as:

00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61 = 7a

If this is the intention, please be explicit (and, ideally, provide an exam= ple).


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Section 2.4:

=C2=A0 (*) The message MUST be sent at this point for the following reasons= :

It's not clear how this normative requirement interacts with this MAY:<= br>
=C2=A0 The second opportunity is just
=C2=A0 before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The =C2=A0 server MAY send EXT_INFO at the second opportunity, whether or not i= t
=C2=A0 sent it at the first.

One seems to merely allow it, while the other seems to demand it. Could you= add
some text that clarifies this apparent contradiction?


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

--001a113fb8f849cfdd05590b8230-- From nobody Tue Sep 12 23:11: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 C02A2132EDA; Tue, 12 Sep 2017 23:11:08 -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 AiqxL0LZ3cN9; Tue, 12 Sep 2017 23:11:05 -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 B6E72132195; Tue, 12 Sep 2017 23:11:04 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id m199so31481631lfe.3; Tue, 12 Sep 2017 23:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vn1moYg/E6znRrBhi7g3uMetPFJ+oe6H1ESfmYVjNoU=; b=vU8P1ZAB4Y8ZNJb1jeHlznkCxkEcpDxh2s46Udx49cOo9FiIxCPtkPax3TKl51Wko6 rlrB000DW0mJsyYIFlr+ogAJmshaZUfbeR9NZ69+mHdfBV3y6T7CWcQ1LAgtyF1dmaKB 8+RgL1k0zmlRp0TNchmFGwr/zd//fMW/p6o2eeqA1/12KrnwtgBxMaM7eOEiDhA0rNua c9WeP9kcD/Lgkq3yDW7Hf+WmVcAHJQH4n0ND5JVeJE5+yQt/8U1kPG54R8wVIjiXNLcp rjpKMlcO81pj9WRYrwWzes/CsozuybL2bxWEjPiGm0W8U4JVi2cZK+/haHE3h6fLpuNk xFvg== 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=vn1moYg/E6znRrBhi7g3uMetPFJ+oe6H1ESfmYVjNoU=; b=KYBPEhrsd0FKCoDwirtrMGbutogV+yj/vfJLH9aF7iOK2Pl0URMFzVnHtVt0Ngw5HZ N6buJC4U0quLj7nsm7Pznq/8KoB8T2+rsRw7MJMLTBLbi8qe7uZusdBfNKUA9AlUiJJ2 Kq+G/Zi9PgONs968erioCDmXZHm3pH3Ft6hQM3pOf30enO/NfsZ0kKAjcVKl68J4WjYw BWTs8RPvkN1Sneh+l7KfAuaN6Q/fXuei8b/d4ilLbm3PNHTb2LyVdLn4Gw8VHiXcaKfJ cTHRlIsvYt1JTF5qOnivVoQ1uBi67DHYq+zKSl9Lx/RZRv/Hvq+m5AQAwE6PfwYkCwc+ DWmQ== X-Gm-Message-State: AHPjjUgmS5JJZx0C5HE6lTmntb/72SEbseW1pLAcQUkDXXP66mbJWqon JSpuLfwEZAAAXfmgOcuQIpSEsrWwKUYeS2dH5sapZg== X-Google-Smtp-Source: AOwi7QC1PNv93/ex4OZ3xH+bWsEvbXfXZeLI9+6HqCteNEzGZJm/ZGmIUmRSbMJSAFjhKwnUvCQyX+deFAtZB3Im9I8= X-Received: by 10.25.84.139 with SMTP id b11mr5037325lfl.78.1505283062974; Tue, 12 Sep 2017 23:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Tue, 12 Sep 2017 23:11:02 -0700 (PDT) In-Reply-To: <150524144548.17894.106479337730195058.idtracker@ietfa.amsl.com> References: <150524144548.17894.106479337730195058.idtracker@ietfa.amsl.com> From: denis bider Date: Wed, 13 Sep 2017 00:11:02 -0600 Message-ID: To: Spencer Dawkins Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1c1b30414c0f05590c069d" Archived-At: Subject: Re: [Curdle] Spencer Dawkins' Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 06:11:09 -0000 --94eb2c1c1b30414c0f05590c069d Content-Type: text/plain; charset="UTF-8" Hello, replies below: > In this text, > > Implementations MUST NOT send an incorrect indicator name for their > role. Implementations MAY disconnect if the counter-party sends an > incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being > negotiated as a key exchange method, the parties MUST disconnect. > > why would a party that doen't support this extention disconnect? This language clarifies a corner case that's not expected to happen. Algorithm negotiation in SSH works like this: For each algorithm type (e.g. key exchange) and direction (for some algorithm types, e.g. encryption): - Server sends a comma-separated namelist of algorithm names in the initial KEX_INFO message. For example: "foo,bar,baz" - Client sends a similar list. For example: "baz,bar" - The negotiated algorithm is (1) the first algorithm in the client's list that (2) also appears in the server's list. In the above example, the negotiated algorithm is "baz". The "ext-info-s" and "ext-info-c" indicators are chosen so that two correct implementations will never negotiate either, because only clients send "ext-info-c", and only servers send "ext-info-s". If one of these algorithms is negotiated, it means either one of the sides is seriously buggy, or there's an attempt at some kind of attack. Therefore, implementations should disconnect. A party that doesn't support EXT_INFO will never see "ext-info-c" or "ext-info-s" being negotiated because it did not send it in its algorithm list. Therefore, it cannot be negotiated. This is unless the party that doesn't support EXT_INFO is sending randomly generated algorithm names and happens to hit upon that one. I trust no honest implementation does this, except for fuzzing. If something like fuzzing results in "ext-info-s" or "ext-info-c" being accidentally negotiated, the aware implementation - of course - is the one that disconnects. > If this extension takes effect, the client MUST send the following > message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: > > byte SSH_MSG_NEWCOMPRESS (value 8) > > I THINK the point is that the client's SSH_MSG_NEWCOMPRESS > is sent after SSH_MSG_USERAUTH_SUCCESS, before the client > sends its first SSH message that's compressed using the newly > negotiated compression algorithm The implication here is that the client might have existing messages in flight to the server when the server sends SSH_MSG_USERAUTH_SUCCESS. This is not often the case, but it is possible: for example, user authentication takes some time, and the client sends a keep-alive message. Because of this potential race condition, the server must wait until it receives SSH_MSG_USERAUTH_SUCCESS before it assumes that compression in the client-to-server direction is in effect. The language says "shortly" because it's hard to say what delay is permissible here. Consider an intentionally pessimized case: - Suppose the server took extremely long to process the authentication attempt. It's not unheard of that login processing can take 5 minutes. - Suppose the client is set up to send frequent keep-alive messages to prevent routers from disconnecting the TCP session, but it does not require the server to respond to them. - Suppose the server blocks and does nothing while it's processing the login attempt. In these circumstances, the server may send SSH_MSG_USERAUTH_SUCCESS, only to find in its TCP input buffer a large number of keep-alive messages from the client which were sent while the server was processing. The server needs to be able to handle all of these messages without compression, before it can expect to receive the client's SSH_MSG_NEWCOMPRESS. My intent here was to encourage clients to send SSH_MSG_NEWCOMPRESS as soon as they are able, while at the same time encouraging servers to tolerate any reasonable number of packets from the client before this message is received - where "reasonable" may be, to some extent, implementation-defined. Based on this feedback, I'm leaning toward changing this language as follows: "If this extension takes effect, the client MUST send the following message within a reasonable number of outgoing messages after receiving SSH_MSG_USERAUTH_SUCCESS - but not necessarily as the first such outgoing message:" Maybe that makes it more clear. The existing, immediately following paragraph attempts to explain the context without trying to dwell on it too long: The purpose of NEWCOMPRESS is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's USERAUTH_SUCCESS. > I would find this easier to understand, if the paragraph defining the > terms was the first paragraph in the section, and then the description > of the extension (which uses the term "elevation") followed. No problem. Will move. > but I could imagine that adding elevation is the first step toward fewer > SSH server implementations that always run with administrative rights > just in case they ever need to use them, so the attack surface is > getting smaller? Yes, that is the case. If clients can't be expected to implement the "elevation" extension, Windows servers must elevate administrative users by default. In a parable - without "elevation", all sessions from administrative users have to run as "root" (on Windows), because there's no way to "sudo". > ... And now I see that Mirja also asked about elevation, and your answer to > her was pretty much what I had guessed. Maybe it's worth summarizing > your answer in section 3.4. I will do so. :-) denis On Tue, Sep 12, 2017 at 12:37 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for a readable document. It was a pleasure to review. > > I have a few comments, but "Spencer doesn't know much about SSH" might be a > fine response for most of them ;-) > > In this text, > > Implementations MUST NOT send an incorrect indicator name for their > role. Implementations MAY disconnect if the counter-party sends an > incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being > negotiated as a key exchange method, the parties MUST disconnect. > > why would a party that doen't support this extention disconnect? > > I ask, because this looks like a MUST requirement that might apply to an > implementation that doesn't support this extension. If that's normal SSH > behavior, that's all I need to know :-) > > In this text, > > If this extension takes effect, the renegotiated compression algorithm > is activated for the very next SSH message after the trigger message: > > - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. > - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. > > If this extension takes effect, the client MUST send the following > message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: > > byte SSH_MSG_NEWCOMPRESS (value 8) > > The purpose of NEWCOMPRESS is to avoid a race condition where the > server cannot reliably know whether a message sent by the client was > sent before or after receiving the server's USERAUTH_SUCCESS. > > I THINK the point is that the client's SSH_MSG_NEWCOMPRESS is sent after > SSH_MSG_USERAUTH_SUCCESS, before the client sends its first SSH message > that's > compressed using the newly negotiated compression algorithm, but "MUST > send ... > shortly after receiving SSH_MSG_USERAUTH_SUCCESS" doesn't help me figure > that > out - I'm mostly guessing, based on "the renegotiated compression > algorithm is > activated for the very next SSH message after the trigger message". But > (1) if > I got that wrong, it's at least unclear for TSV ADs, and (2) if I got that > right, I'm not understanding what "shortly after receiving" the trigger > message > is saying - for example, I wondered if there's a timer involved, so that > if a > client doesn't have messages to send, it should still send > SSH_MSG_NEWCOMPRESS, > or the server will think something's wrong. > > In this text, > > This extension MAY be sent by the client as follows: > > string "elevation" > string choice of: "y" | "n" | "d" > > A client sends "y" to indicate its preference that the session should > be elevated; "n" to not be elevated; and "d" for the server to use its > default behavior. The server MAY disconnect if it receives a different > extension value. If a client does not send the "elevation" extension, > the server SHOULD act as if "d" was sent. > > The terms "elevation" and "elevated" refer to an operating system > mechanism where an administrator user's logon session is associated > with two security contexts: one limited, and one with administrative > rights. To "elevate" such a session is to activate the security > context with full administrative rights. For more information about > this mechanism on Windows, see also [WINADMIN] and [WINTOKEN]. > > If a client has included this extension, then after authentication, a > server that supports this extension SHOULD indicate to the client > whether elevation was done by sending the following global request: > > byte SSH_MSG_GLOBAL_REQUEST > string "elevation" > boolean want reply = false > boolean elevation performed > > I would find this easier to understand, if the paragraph defining the > terms was > the first paragraph in the section, and then the description of the > extension > (which uses the term "elevation") followed. It's not bad, the way it is, > but > the reader has to read past the description to find out what the definition > means. > > The security considerations are brief and refer to overarching security > considerations, which I understand because this is an extension, but > > Security considerations are discussed throughout this document. This > document updates the SSH protocol as defined in [RFC4251] and related > documents. The security considerations of [RFC4251] apply. > > doesn't say anything about new security considerations to think about, > when you > add support for elevation, which seems like it would be a new attack > surface, > but I could imagine that adding elevation is the first step toward fewer > SSH > server implementations that always run with administrative rights just in > case > they ever need to use them, so the attack surface is getting smaller? > > ... And now I see that Mirja also asked about elevation, and your answer > to her > was pretty much what I had guessed. Maybe it's worth summarizing your > answer > in section 3.4. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c1c1b30414c0f05590c069d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

replies below:
<= div>

>=C2=A0In = this text,
>
> =C2=A0Implementations MUST NO= T send an incorrect indicator name for their
> =C2=A0role. Implementations MA= Y disconnect if the counter-party sends an
> =C2=A0incorrect indicator. If &q= uot;ext-info-c" or "ext-info-s" ends up being
> =C2=A0negotiat= ed as a key exchange method, the parties MUST disconnect.
>
> why would a party that doen't support this extentio= n disconnect?

This language clarifies a corner ca= se that's not expected to happen. Algorithm negotiation in SSH works li= ke this:

For each algorithm type (e.g. key exchang= e) and direction (for some algorithm types, e.g. encryption):
- Server sends a comma-separated namelist of algorithm names in= the initial KEX_INFO message. For example: "foo,bar,baz"
- Client sends a similar list. For example: "baz,bar"
- The negotiated algorithm is (1) the first algorithm in the client's= list that (2) also appears in the server's list.

<= div>In the above example, the negotiated algorithm is "baz".

The "ext-info-s" and "ext-info-c" = indicators are chosen so that two correct implementations will never negoti= ate either, because only clients send "ext-info-c", and only serv= ers send "ext-info-s". If one of these algorithms is negotiated, = it means either one of the sides is seriously buggy, or there's an atte= mpt at some kind of attack. Therefore, implementations should disconnect.

A party that doesn't support EXT_INFO will neve= r see "ext-info-c" or "ext-info-s" being negotiated bec= ause it did not send it in its algorithm list. Therefore, it cannot be nego= tiated.

This is unless the party that doesn't = support EXT_INFO is sending randomly generated algorithm names and happens = to hit upon that one. I trust no honest implementation does this, except fo= r fuzzing. If something like fuzzing results in "ext-info-s" or &= quot;ext-info-c" being accidentally negotiated, the aware implementati= on - of course - is the one that disconnects.


=
> =C2=A0=C2=A0If this extens= ion takes effect, the client MUST send the following
> =C2=A0 message shortly after receiving SSH_MSG_= USERAUTH_SUCCESS:
>
> =C2=A0 =C2=A0 =C2=A0byte=C2=A0 =C2=A0 =C2=A0 =C2= =A0SSH_MSG_NEWCOMPRESS (value 8)
>
>=C2=A0= I THINK the point is that the client's= SSH_MSG_NEWCOMPRESS
>= is sent after=C2=A0SSH_MSG_USERAUT= H_SUCCESS, before the client
> sends its first SSH message that's=C2=A0compressed using the newly
> negotiated compression algorithm
=
The implication here is that the client might have existing = messages in flight to the server when the server sends SSH_MSG_USERAUTH_SUC= CESS. This is not often the case, but it is possible: for example, user aut= hentication takes some time, and the client sends a keep-alive message.

Because of this potential race condition, the server = must wait until it receives SSH_MSG_USERAUTH_SUCCESS before it assumes that= compression in the client-to-server direction is in effect.

=
The language says "shortly" because it's hard to s= ay what delay is permissible here. Consider an intentionally pessimized cas= e:

- Suppose the server took extremely long to pro= cess the authentication attempt. It's not unheard of that login process= ing can take 5 minutes.
- Suppose the client is set up to send fr= equent keep-alive messages to prevent routers from disconnecting the TCP se= ssion, but it does not require the server to respond to them.
- S= uppose the server blocks and does nothing while it's processing the log= in attempt.

In these circumstances, the server may= send SSH_MSG_USERAUTH_SUCCESS, only to find in its TCP input buffer a larg= e number of keep-alive messages from the client which were sent while the s= erver was processing. The server needs to be able to handle all of these me= ssages without compression, before it can expect to receive the client'= s SSH_MSG_NEWCOMPRESS.

My intent here was to encou= rage clients to send SSH_MSG_NEWCOMPRESS as soon as they are able, while at= the same time encouraging servers to tolerate any reasonable number of pac= kets from the client before this message is received - where "reasonab= le" may be, to some extent, implementation-defined.

Based on this feedback, I'm leaning toward changing this languag= e as follows:

"If=C2=A0this extension takes effect, the client MUST send the follo= wing=C2=A0message within a reasonab= le number of outgoing messages after receiving SSH_MSG_USERAUTH_SUCCESS - b= ut not necessarily as the first such outgoing message:"

Maybe that makes it more clear. The existing, immedia= tely following paragraph attempts to explain the context without trying to = dwell on it too long:
=C2=A0 =C2=A0 The purpo= se of NEWCOMPRESS is to avoid a race condition where the
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0 server cannot reliably know w= hether a message sent by the client was
=C2=A0 =C2=A0 sent before or after receiving the server'= s USERAUTH_SUCCESS.

<= /span>

>=C2=A0I would find this easier to understand, if the paragraph defining the<= /span>
> terms was=C2=A0the first paragraph in the section, and = then the description
>= of the extension=C2=A0(which uses = the term "elevation") followed.

No = problem. Will move.

<= /span>

>=C2=A0but I could imagine that adding elevation is the first step toward few= er
> SSH=C2=A0server implementations that always run = with administrative rights
> just in case=C2=A0they ever = need to use them, so the attack surface is
> getting smaller?

Yes, = that is the case.=C2=A0If clients c= an't be expected to implement the "elevation" extension, Wind= ows servers must elevate administrative users by default.
=
In a parable - without "elevation", all sessions fro= m administrative users have to run as "root" (on Windows), becaus= e there's no way to "sudo".

>=C2=A0... And now I see that Mirja also asked about el= evation, and your answer to
> her=C2=A0was pretty much wh= at I had guessed.=C2=A0 Maybe it's worth summarizing
<= span style=3D"font-size:12.8px">> your answer=C2=A0in section 3.4.

I will d= o so. :-)

denis



On Tue, Sep 12, 2017 at 12:= 37 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com><= /span> wrote:
Spencer Dawkins has entered= the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Thanks for a readable document. It was a pleasure to review.

I have a few comments, but "Spencer doesn't know much about SSH&qu= ot; might be a
fine response for most of them ;-)

In this text,

=C2=A0 Implementations MUST NOT send an incorrect indicator name for their<= br> =C2=A0 role. Implementations MAY disconnect if the counter-party sends an =C2=A0 incorrect indicator. If "ext-info-c" or "ext-info-s&q= uot; ends up being
=C2=A0 negotiated as a key exchange method, the parties MUST disconnect.
why would a party that doen't support this extention disconnect?

I ask, because this looks like a MUST requirement that might apply to an implementation that doesn't support this extension. If that's norma= l SSH
behavior, that's all I need to know :-)

In this text,

=C2=A0 If this extension takes effect, the renegotiated compression algorit= hm
=C2=A0 is activated for the very next SSH message after the trigger message= :

=C2=A0 - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCES= S.
=C2=A0 - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.
=C2=A0 If this extension takes effect, the client MUST send the following =C2=A0 message shortly after receiving SSH_MSG_USERAUTH_SUCCESS:

=C2=A0 =C2=A0 byte=C2=A0 =C2=A0 =C2=A0 =C2=A0SSH_MSG_NEWCOMPRESS (value 8)<= br>
=C2=A0 The purpose of NEWCOMPRESS is to avoid a race condition where the =C2=A0 server cannot reliably know whether a message sent by the client was=
=C2=A0 sent before or after receiving the server's USERAUTH_SUCCESS.
I THINK the point is that the client's SSH_MSG_NEWCOMPRESS is sent afte= r
SSH_MSG_USERAUTH_SUCCESS, before the client sends its first SSH message tha= t's
compressed using the newly negotiated compression algorithm, but "MUST= send ...
shortly after receiving SSH_MSG_USERAUTH_SUCCESS" doesn't help me = figure that
out - I'm mostly guessing, based on "the renegotiated compression = algorithm is
activated for the very next SSH message after the trigger message". Bu= t (1) if
I got that wrong, it's at least unclear for TSV ADs, and (2) if I got t= hat
right, I'm not understanding what "shortly after receiving" t= he trigger message
is saying - for example, I wondered if there's a timer involved, so tha= t if a
client doesn't have messages to send, it should still send SSH_MSG_NEWC= OMPRESS,
or the server will think something's wrong.

In this text,

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

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

=C2=A0 A client sends "y" to indicate its preference that the ses= sion should
=C2=A0 be elevated; "n" to not be elevated; and "d" for= the server to use its
=C2=A0 default behavior. The server MAY disconnect if it receives a differe= nt
=C2=A0 extension value. If a client does not send the "elevation"= extension,
=C2=A0 the server SHOULD act as if "d" was sent.

=C2=A0 The terms "elevation" and "elevated" refer to an= operating system
=C2=A0 mechanism where an administrator user's logon session is associa= ted
=C2=A0 with two security contexts: one limited, and one with administrative=
=C2=A0 rights. To "elevate" such a session is to activate the sec= urity
=C2=A0 context with full administrative rights. For more information about<= br> =C2=A0 this mechanism on Windows, see also [WINADMIN] and [WINTOKEN].

=C2=A0 If a client has included this extension, then after authentication, = a
=C2=A0 server that supports this extension SHOULD indicate to the client =C2=A0 whether elevation was done by sending the following global request:<= br>
=C2=A0 =C2=A0 byte=C2=A0 =C2=A0 =C2=A0 =C2=A0 SSH_MSG_GLOBAL_REQUEST
=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 "elevation"
=C2=A0 =C2=A0 boolean=C2=A0 =C2=A0 =C2=A0want reply =3D false
=C2=A0 =C2=A0 boolean=C2=A0 =C2=A0 =C2=A0elevation performed

I would find this easier to understand, if the paragraph defining the terms= was
the first paragraph in the section, and then the description of the extensi= on
(which uses the term "elevation") followed. It's not bad, the= way it is, but
the reader has to read past the description to find out what the definition=
means.

The security considerations are brief and refer to overarching security
considerations, which I understand because this is an extension, but

=C2=A0 Security considerations are discussed throughout this document. This=
=C2=A0 document updates the SSH protocol as defined in [RFC4251] and relate= d
=C2=A0 documents. The security considerations of [RFC4251] apply.

doesn't say anything about new security considerations to think about, = when you
add support for elevation, which seems like it would be a new attack surfac= e,
but I could imagine that adding elevation is the first step toward fewer SS= H
server implementations that always run with administrative rights just in c= ase
they ever need to use them, so the attack surface is getting smaller?

... And now I see that Mirja also asked about elevation, and your answer to= her
was pretty much what I had guessed.=C2=A0 Maybe it's worth summarizing = your answer
in section 3.4.


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

--94eb2c1c1b30414c0f05590c069d-- From nobody Wed Sep 13 04:46:17 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153D613334E; Wed, 13 Sep 2017 04:46:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 04:46:10 -0700 Archived-At: Subject: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) 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, 13 Sep 2017 11:46:10 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- RFC 6234 must be normative, as it is required to implement this document. From nobody Wed Sep 13 05:00:30 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 CEB23134215; Wed, 13 Sep 2017 05:00:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 05:00:27 -0700 Archived-At: Subject: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) 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, 13 Sep 2017 12:00:28 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is generally a good and useful document. I have some minor comments I would like to discuss: 3.2. "delay-compression" This extension MAY be sent by both parties as follows: string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client It is not clear for me from the formatting whether the first name-list is sent by the client and the second by the server, or both lists are always included in the value. I suspect it is the former, but can you please clarify? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sentences like: Use of Receivers MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension's extension-value. or In particular, applications MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension's extension-value. Use of punctuation is not my strongest point, but I am reasonably certain that use of ";" is not correct here. I think you should use (). Otherwise these sentences are reading as a list of 3 things, yet in both cases the 3rd is a continuation of the 1st. 2) In Section 2.5: The relative order in which extensions appear in an EXT_INFO message MUST be ignored by default; but an extension MAY specify that the order matters for that extension, in a specific way. Can you provide an example of why depending on order would be useful? This potentially makes it harder to implement. In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be less confusing if you used the latter consistently everywhere. 3) In 3.1: This extension is sent by the server, and contains a list of public key algorithms that the server is able to process as part of a "publickey" authentication request. If a client sends this extension, the server MAY ignore it, and MAY disconnect. Why would the client disconnect when seeing this extension? Does it mean it is broken? Also, as the client can always disconnect at any point, why mentioning this here? If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected public key algorithm. Can you elaborate on what do you mean by "authentication penalties" in this context? From nobody Wed Sep 13 05:56: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 6140A1241F3; Wed, 13 Sep 2017 05:56:27 -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 bqnbEmin0yNp; Wed, 13 Sep 2017 05:56:24 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 264A4132A1A; Wed, 13 Sep 2017 05:56:24 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id 80so350425lfy.4; Wed, 13 Sep 2017 05:56:24 -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=xUNb2YMWk9Gh6GnFO764rkzM/Kt8X4Yz/RfmH+roUZc=; b=GDO/xFfbcFe6DJ9Zc8an78VzkFVSnH1BycQ46Ks8worI29y0G+leSIIzt2MJBhBxud mx6JXvK0SlXogeoLkt2eP9/wX23Cs4jwscnTPAv/JMn8YO9GS88ZaYsnDV10qsaHIP5H oowLNOgw6+9cHOesvTtZsJ0ItVxuoP4MsnptgPTQP0C3vpefFK6USdKXE+MqocnHvu8w 30SOGsNHQCl5Oj9+AYoUAVehL3ut/JU3x14OFK2A8Kqp3gMan6FBPvFveKk7/VVngqAN uEaA06cZHfgazhOw9qh8fCOAx8T+dcFMSLnqbHk9Nj3bHuPIp7ST41o1tyOyGgGc3/tY 0L6A== 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=xUNb2YMWk9Gh6GnFO764rkzM/Kt8X4Yz/RfmH+roUZc=; b=k5Ti/HrE50jOa7ydD3Iu/0jR090S/zaMbEx1tq+DuudTRRFhxdvllPXWFsm89/Q3yn ifly/Lz9LoqdDbuPyRasVRPZugkv3w56uuB3oVrDRs8fkumHOyG3gUvaxteOgzyMFmbs To0HB4bcBH56rJwzD4cIgTsOIbdEialTp+5floJSMgFSbbhpPRsFxQHy8xGKLgxHz70v ai91Pa1NBt4C24JWon4oCOwpXbmVuOOmUpwoHg9RQXYZzfBdMi/9cdyG8JZ0oPa+ls7A of2SPQFaCoQRYeZWzkoFfj5vx0ImrjGh/a2pB4B0RLxNJaJYsl5XW+adeDYf8Y7H6nmS 8PuQ== X-Gm-Message-State: AHPjjUhfsN5YeNU8M8HrEVzJKRYPf/Zrf/rNdWWa+E9M+g5c1wPZxgco guWHkNbcXBwCeMd7P6DbFbrYT2ohpJ/8xDO/3Gc= X-Google-Smtp-Source: ADKCNb7kWgOMJ+1lBTMc7q4ytkrxW7fikKTMC/KuCCMzryk+21PL7kHyxSR4lVpLMgO9V3wME4HtcantmtgOcfBZE4s= X-Received: by 10.46.20.27 with SMTP id u27mr5239698ljd.39.1505307382392; Wed, 13 Sep 2017 05:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Wed, 13 Sep 2017 05:56:21 -0700 (PDT) In-Reply-To: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> From: denis bider Date: Wed, 13 Sep 2017 06:56:21 -0600 Message-ID: To: Alexey Melnikov Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="f403045fbb90ce2c0e055911af0f" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 12:56:27 -0000 --f403045fbb90ce2c0e055911af0f Content-Type: text/plain; charset="UTF-8" > It is not clear for me from the formatting whether the first > name-list is sent by the client and the second by the server, > or both lists are always included in the value. I suspect it > is the former, but can you please clarify? SSH negotiates compression, integrity, and encryption algorithms separately for each direction. Both lists are sent by both parties. Not just here, but also in KEXINIT. This is used rarely in practice, but this draft keeps to the same practice, so as not to bundle a reduction of functionality (i.e. requiring same compression for both directions) in the same package as an extension (i.e. providing a mechanism for delayed activation of compression). The next draft will include an example of encoding, as suggested by Adam. This should make things clearer, even for readers unfamiliar with SSH. > 1) Sentences like: > Use of Receivers MUST tolerate any sequence of bytes; including > null bytes at any position; in an unknown extension's extension-value. Reads fine to me. Still, I changed these to use dashes. > Can you provide an example of why depending on order > would be useful? This potentially makes it harder to implement. It is the nature of an extension mechanism that it intends to be open to unforeseen circumstances. If we could come up with examples for all possible future uses, extensions would not be required. For this reason, I would prefer if you can demonstrate how allowing for this possibility makes anything harder to implement. In my implementation experience, it doesn't. > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. > It would be less confusing if you used the latter consistently everywhere. This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, NEWCOMPRESS, and USERAUTH_SUCCESS. OK, I changed this to use the SSH_MSG_ prefix always. > This extension is sent by the server, and contains a list of public > key algorithms that the server is able to process as part of a > "publickey" authentication request. If a client sends this extension, > the server MAY ignore it, and MAY disconnect. > > Why would the client disconnect when seeing this extension? Does it mean it is > broken? > > Also, as the client can always disconnect at any point, why mentioning this > here? I believe you have misread the text in this case. It should be clear from the above quoted snippet. > Can you elaborate on what do you mean by "authentication penalties" > in this context? SSH servers commonly implement some way of locking out or throttling IP addresses that make frequent login attempts, so as to deter brute force password guessing, username guessing, and similar undesired behaviors. Some servers apply such penalties to clients that attempt to use an unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the client's IP address being locked out. The "server-sig-algs" extension provides a way for the client to know that the server supports e.g. "rsa-sha2-256" before it attempts to use it, to avoid a potential IP lockout. On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is generally a good and useful document. I have some minor comments I > would like to discuss: > > 3.2. "delay-compression" > > This extension MAY be sent by both parties as follows: > > string "delay-compression" > string: > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > > It is not clear for me from the formatting whether the first name-list is > sent > by the client and the second by the server, or both lists are always > included > in the value. I suspect it is the former, but can you please clarify? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) Sentences like: > Use of Receivers MUST tolerate any sequence of bytes; including null > bytes > at any position; in an unknown extension's extension-value. > or > In particular, applications MUST tolerate any sequence of bytes; > including > null bytes at any position; in an unknown extension's extension-value. > > Use of punctuation is not my strongest point, but I am reasonably certain > that > use of ";" is not correct here. I think you should use (). Otherwise these > sentences are reading as a list of 3 things, yet in both cases the 3rd is a > continuation of the 1st. > > 2) In Section 2.5: > > The relative order in which extensions appear in an > EXT_INFO message MUST be ignored by default; but an extension MAY > specify that the order matters for that extension, in a specific way. > > Can you provide an example of why depending on order would be useful? This > potentially makes it harder to implement. > > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be > less confusing if you used the latter consistently everywhere. > > 3) In 3.1: > > This extension is sent by the server, and contains a list of public > key algorithms that the server is able to process as part of a > "publickey" authentication request. If a client sends this extension, > the server MAY ignore it, and MAY disconnect. > > Why would the client disconnect when seeing this extension? Does it mean > it is > broken? > > Also, as the client can always disconnect at any point, why mentioning this > here? > > If a server does not send this extension, a client MUST NOT make any > assumptions about the server's public key algorithm support, and MAY > proceed with authentication requests using trial and error. Note that > implementations are known to exist that apply authentication penalties > if the client attempts to use an unexpected public key algorithm. > > Can you elaborate on what do you mean by "authentication penalties" in this > context? > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045fbb90ce2c0e055911af0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0It is not clear= for me from the formatting whether the first
> name-list is sent=C2=A0by the client and the second by the server,
> or both lists are always included=C2=A0in the value. I suspect it
=
> is the former, but can you pleas= e clarify?

SSH= negotiates compression, integrity, and encryption algorithms separately fo= r each direction. Both lists are sent by both parties. Not just here, but a= lso in KEXINIT.

This is used rarely in practi= ce, but this draft keeps to the same practice, so as not to bundle a reduct= ion of functionality (i.e. requiring same compression for both directions) = in the same package as an extension (i.e. providing a mechanism for delayed= activation of compression).

The next dra= ft will include an example of encoding, as suggested by Adam. This should m= ake things clearer, even for readers unfamiliar with SSH.
=

>=C2=A01) Sentences like:
> Use= of=C2=A0 Receivers MUST tolerate any sequence of bytes; including> null bytes=C2=A0at any position; in an unknown extension's extens= ion-value.

Reads fine to me. Still, I changed these= to use dashes.


>=C2=A0Can you provide an example of why depen= ding on order
> would = be useful? This=C2=A0potentially ma= kes it harder to implement.

It is the nature = of an extension mechanism that it intends to be open to unforeseen circumst= ances. If we could come up with examples for all possible future uses, exte= nsions would not be required.

For this reason= , I would prefer if you can demonstrate how allowing for this possibility m= akes anything harder to implement. In my implementation experience, it does= n't.


>=C2=A0In sev= eral places you use EXT_INFO instead of SSH_MSG_EXT_INFO.
= > It would be=C2=A0less confusing if you used the latter consistently ev= erywhere.

This doesn't just go for EXT_IN= FO, it also goes for KEXINIT, NEWKEYS, NEWCOMPRESS, and USERAUTH_SUCCESS.

OK, I changed this to use the SSH_MSG_ prefix = always.

=

>=C2=A0=C2=A0 = This extension is sent by the server, and contains a list of public<= /div>> =C2=A0 key algorithms that the s= erver is able to process as part of a
= > =C2=A0 "publickey" authenti= cation request. If a client sends this extension,
> =C2=A0 the server MAY ign= ore it, and MAY disconnect.
>
> Why would the client disconnect when seeing this extension? Does it= mean it is
> broken?
>=C2=A0
> Also, as the c= lient can always disconnect at any point, why mentioning this
> here?<= /div>

I believe you have misread the text in this case. It= should be clear from the above quoted snippet.


>=C2=A0= Can you elaborate on what do you mean by &= quot;authentication penalties"
> in this=C2=A0contex= t?

=
SSH servers commonly implement some w= ay of locking out or throttling IP addresses that make frequent login attem= pts, so as to deter brute force password guessing, username guessing, and s= imilar undesired behaviors.

Some servers appl= y such penalties to clients that attempt to use an unknown public key algor= ithm (e.g. "rsa-sha2-256"). This can result in the client's I= P address being locked out.

The "server-= sig-algs" extension provides a way for the client to know that the ser= ver supports e.g. "rsa-sha2-256" before it attempts to use it, to= avoid a potential IP lockout.



On Wed, Sep 13, 2017 at 6:00 AM, Alexey M= elnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot positio= n for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is generally a good and useful document. I have some minor comments I<= br> would like to discuss:

3.2.=C2=A0 "delay-compression"

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

=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-compressi= on"
=C2=A0 =C2=A0 string:
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_client_<= wbr>to_server
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_server_<= wbr>to_client

It is not clear for me from the formatting whether the first name-list is s= ent
by the client and the second by the server, or both lists are always includ= ed
in the value. I suspect it is the former, but can you please clarify?


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) Sentences like:
=C2=A0 Use of=C2=A0 Receivers MUST tolerate any sequence of bytes; includin= g null bytes
=C2=A0 at any position; in an unknown extension's extension-value.
or
=C2=A0In particular, applications MUST=C2=A0 tolerate any sequence of bytes= ; including
=C2=A0null bytes at any position;=C2=A0 in an unknown extension's exten= sion-value.

Use of punctuation is not my strongest point, but I am reasonably certain t= hat
use of ";" is not correct here. I think you should use (). Otherw= ise these
sentences are reading as a list of 3 things, yet in both cases the 3rd is a=
continuation of the 1st.

2) In Section 2.5:

=C2=A0The relative order in which extensions appear in an
=C2=A0 EXT_INFO message MUST be ignored by default; but an extension MAY =C2=A0 specify that the order matters for that extension, in a specific way= .

Can you provide an example of why depending on order would be useful? This<= br> potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be=
less confusing if you used the latter consistently everywhere.

3) In 3.1:

=C2=A0 This extension is sent by the server, and contains a list of public<= br> =C2=A0 key algorithms that the server is able to process as part of a
=C2=A0 "publickey" authentication request. If a client sends this= extension,
=C2=A0 the server MAY ignore it, and MAY disconnect.

Why would the client disconnect when seeing this extension? Does it mean it= is
broken?

Also, as the client can always disconnect at any point, why mentioning this=
here?

=C2=A0 If a server does not send this extension, a client MUST NOT make any=
=C2=A0 assumptions about the server's public key algorithm support, and= MAY
=C2=A0 proceed with authentication requests using trial and error. Note tha= t
=C2=A0 implementations are known to exist that apply authentication penalti= es
=C2=A0 if the client attempts to use an unexpected public key algorithm.
Can you elaborate on what do you mean by "authentication penalties&quo= t; in this
context?


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

--f403045fbb90ce2c0e055911af0f-- From nobody Wed Sep 13 06:12: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 08F2D133038; Wed, 13 Sep 2017 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.fm header.b=dJrwseQO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H/jU4q+A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXUlsLMU-JJ8; Wed, 13 Sep 2017 06:12:07 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C8F132D14; Wed, 13 Sep 2017 06:12:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ED27420E04; Wed, 13 Sep 2017 09:12:05 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 13 Sep 2017 09:12:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=0oNuXG2kvzO7JMb8KFiNgrYCc8PXb F4S5mVdSLxuLuc=; b=dJrwseQOneNYGMkNk4U4gn7GtoFA/uJqEHhy/MaM7teA2 HbvK044Pl5IKm7axWecz/0AQdBeyEqzfz+PvGI3jBtBrOfx4Etf7+3LGvpcvIo2I WMiGMqliM0LP6W7zh7zox4ArotNMlfLCF1wYFsSsQLVFMUi++8DqDtmMtyK5sHhI h/qV53JphScHObYIkeNnuhiGrt0tsyAEbKcmXlrS/Bi5NU5PJG4ltswSaRZxAyvY BTQQqatMiphINM7VFHtHP3bB7qr4ck4tTsQzE4yma8G+CUQUJP0cWPKrrjWXemzM yhyIu93UTQGTA77rsKWAyc+JUQqe6joA/dab7pbOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0oNuXG 2kvzO7JMb8KFiNgrYCc8PXbF4S5mVdSLxuLuc=; b=H/jU4q+AzI2M/wqKZGruJo vzbeFYgJcjyEBr+VwLm8oEp281B9WHgQrASOFh8WSn9Cb/KptmJptktiXfFWy4iz InKtXUqBp1C2sXXQB9/hqMSAq9VKy41+mSZwj5i7Sqvxc4skd/DyZUqRj9ufM5Jk DKzEJ3kouyHuEa5/1wSOIYVMVgYmztnvQZrHPohTBJGBEnQn5bnkGvceJ2bcbv4v zwHa24XDLH5k+FEcbQb3vzWrGLJCLDT9U3ZpBDUN9VCKd93coj2l5VFd8PYoiW6Q bJxDcpr4WW+yTEbAzLF7DUf+RHm3SIsrjHZF2ThL4OrdkWzIpAGvAQFv32ZHPurw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C50909E2E4; Wed, 13 Sep 2017 09:12:05 -0400 (EDT) Message-Id: <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> From: Alexey Melnikov To: denis bider Cc: The IESG , Daniel Migault , "curdle-chairs" , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150530832520629931" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 14:12:05 +0100 In-Reply-To: Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 13:12:10 -0000 This is a multi-part message in MIME format. --_----------=_150530832520629931 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote: > > It is not clear for me from the formatting whether the first > > name-list is sent by the client and the second by the server, > > or both lists are always included in the value. I suspect it > > is the former, but can you please clarify? > > SSH negotiates compression, integrity, and encryption algorithms > separately for each direction. Both lists are sent by both parties. > Not just here, but also in KEXINIT.> > This is used rarely in practice, but this draft keeps to the same > practice, so as not to bundle a reduction of functionality (i.e. > requiring same compression for both directions) in the same package as > an extension (i.e. providing a mechanism for delayed activation of > compression).> > The next draft will include an example of encoding, as suggested by > Adam. This should make things clearer, even for readers unfamiliar > with SSH.Yes, I think this will help. If you can list an example here for both the client side and the server side, that would be great. > > > 1) Sentences like: > > Use of Receivers MUST tolerate any sequence of bytes; including > > null bytes at any position; in an unknown extension's extension- > > value.> > Reads fine to me. Still, I changed these to use dashes. > > > > Can you provide an example of why depending on order > > would be useful? This potentially makes it harder to implement. > > It is the nature of an extension mechanism that it intends to be open > to unforeseen circumstances. If we could come up with examples for all > possible future uses, extensions would not be required.> > For this reason, I would prefer if you can demonstrate how allowing > for this possibility makes anything harder to implement. In my > implementation experience, it doesn't.I implemented multiple capability negotiation frameworks and very few of them (at the moment I can't think of any, actually) have dependencies on order. Dealing with one element at a time seems a bit simpler. My gut feeling is that you will never need this, so I wanted to know if you actually can provide an example that depends on order. > > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. > > It would be less confusing if you used the latter consistently > > everywhere.> > This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, > NEWCOMPRESS, and USERAUTH_SUCCESS.> > OK, I changed this to use the SSH_MSG_ prefix always. Thank you. > > > This extension is sent by the server, and contains a list of > > public> > key algorithms that the server is able to process as part of a > > "publickey" authentication request. If a client sends this > > extension,> > the server MAY ignore it, and MAY disconnect. > > > > Why would the client disconnect when seeing this extension? Does it > > mean it is> > broken? > > > > Also, as the client can always disconnect at any point, why > > mentioning this> > here? > > I believe you have misread the text in this case. It should be clear > from the above quoted snippet.Oh, do you mean that this is never supposed to be sent by the client? In this case, yes, I misread it. Never mind. > > > Can you elaborate on what do you mean by "authentication penalties"> > in this context? > > SSH servers commonly implement some way of locking out or throttling > IP addresses that make frequent login attempts, so as to deter brute > force password guessing, username guessing, and similar undesired > behaviors.> > Some servers apply such penalties to clients that attempt to use an > unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in > the client's IP address being locked out.> > The "server-sig-algs" extension provides a way for the client to know > that the server supports e.g. "rsa-sha2-256" before it attempts to use > it, to avoid a potential IP lockout.I think explaining this in the document would be useful. "Penalties" sounds a bit vague. > On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov > wrote:>> Alexey Melnikov has entered the following ballot position for >> draft-ietf-curdle-ssh-ext-info-12: Discuss >> >> When responding, please keep the subject line intact and reply >> to all>> email addresses included in the To and CC lines. (Feel free to >> cut this>> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html>> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here:>> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ >> >> >> >> ---------------------------------------------------------------- >> ------>> DISCUSS: >> ---------------------------------------------------------------- >> ------>> >> This is generally a good and useful document. I have some minor >> comments I>> would like to discuss: >> >> 3.2. "delay-compression" >> >> This extension MAY be sent by both parties as follows: >> >> string "delay-compression" >> string: >> name-list compression_algorithms_client_to_server >> name-list compression_algorithms_server_to_client >> >> It is not clear for me from the formatting whether the first name- >> list is sent>> by the client and the second by the server, or both lists are always >> included>> in the value. I suspect it is the former, but can you please >> clarify?>> >> >> ---------------------------------------------------------------- >> ------>> COMMENT: >> ---------------------------------------------------------------- >> ------>> >> 1) Sentences like: >> Use of Receivers MUST tolerate any sequence of bytes; including >> null bytes>> at any position; in an unknown extension's extension-value. >> or >> In particular, applications MUST tolerate any sequence of bytes; >> including>> null bytes at any position; in an unknown extension's extension- >> value.>> >> Use of punctuation is not my strongest point, but I am reasonably >> certain that>> use of ";" is not correct here. I think you should use (). >> Otherwise these>> sentences are reading as a list of 3 things, yet in both cases the >> 3rd is a>> continuation of the 1st. >> >> 2) In Section 2.5: >> >> The relative order in which extensions appear in an >> EXT_INFO message MUST be ignored by default; but an extension MAY>> specify that the order matters for that extension, in a specific >> way.>> >> Can you provide an example of why depending on order would be >> useful? This>> potentially makes it harder to implement. >> >> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It >> would be>> less confusing if you used the latter consistently everywhere. >> >> 3) In 3.1: >> >> This extension is sent by the server, and contains a list of >> public>> key algorithms that the server is able to process as part of a >> "publickey" authentication request. If a client sends this >> extension,>> the server MAY ignore it, and MAY disconnect. >> >> Why would the client disconnect when seeing this extension? Does it >> mean it is>> broken? >> >> Also, as the client can always disconnect at any point, why >> mentioning this>> here? >> >> If a server does not send this extension, a client MUST NOT >> make any>> assumptions about the server's public key algorithm support, >> and MAY>> proceed with authentication requests using trial and error. Note >> that>> implementations are known to exist that apply authentication >> penalties>> if the client attempts to use an unexpected public key algorithm.>> >> Can you elaborate on what do you mean by "authentication penalties" >> in this>> context? >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle --_----------=_150530832520629931 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote:
> It is not clear for me from the formatting whether the first
> name-list is sent by the client and the second by the server,
> or both lists are always included in the value. I suspect it
> is the former, but can you please clarify?

SSH negotiates compression, integrity, and encryption algorithms separately for each direction. Both lists are sent by both parties. Not just here, but also in KEXINIT.

This is used rarely in practice, but this draft keeps to the same practice, so as not to bundle a reduction of functionality (i.e. requiring same compression for both directions) in the same package as an extension (i.e. providing a mechanism for delayed activation of compression).

The next draft will include an example of encoding, as suggested by Adam. This should make things clearer, even for readers unfamiliar with SSH.
Yes, I think this will help. If you can list an example here for both the client side and the server side, that would be great.


> 1) Sentences like:
> Use of  Receivers MUST tolerate any sequence of bytes; including
> null bytes at any position; in an unknown extension's extension-value.

Reads fine to me. Still, I changed these to use dashes.


> Can you provide an example of why depending on order
> would be useful? This potentially makes it harder to implement.

It is the nature of an extension mechanism that it intends to be open to unforeseen circumstances. If we could come up with examples for all possible future uses, extensions would not be required.

For this reason, I would prefer if you can demonstrate how allowing for this possibility makes anything harder to implement. In my implementation experience, it doesn't.
I implemented multiple capability negotiation frameworks and very few of them (at the moment I can't think of any, actually) have dependencies on order. Dealing with one element at a time seems a bit simpler.

My gut feeling is that you will never need this, so I wanted to know if you actually can provide an example that depends on order.

> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO.
> It would be less confusing if you used the latter consistently everywhere.

This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, NEWCOMPRESS, and USERAUTH_SUCCESS.

OK, I changed this to use the SSH_MSG_ prefix always.
Thank you.


>   This extension is sent by the server, and contains a list of public
>   key algorithms that the server is able to process as part of a
>   "publickey" authentication request. If a client sends this extension,
>   the server MAY ignore it, and MAY disconnect.
>
> Why would the client disconnect when seeing this extension? Does it mean it is
> broken?
> 
> Also, as the client can always disconnect at any point, why mentioning this
> here?

I believe you have misread the text in this case. It should be clear from the above quoted snippet.
Oh, do you mean that this is never supposed to be sent by the client? In this case, yes, I misread it. Never mind.


> Can you elaborate on what do you mean by "authentication penalties"
> in this context?

SSH servers commonly implement some way of locking out or throttling IP addresses that make frequent login attempts, so as to deter brute force password guessing, username guessing, and similar undesired behaviors.

Some servers apply such penalties to clients that attempt to use an unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the client's IP address being locked out.

The "server-sig-algs" extension provides a way for the client to know that the server supports e.g. "rsa-sha2-256" before it attempts to use it, to avoid a potential IP lockout.
I think explaining this in the document would be useful. "Penalties" sounds a bit vague.

On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a good and useful document. I have some minor comments I
would like to discuss:

3.2.  "delay-compression"

  This extension MAY be sent by both parties as follows:

    string         "delay-compression"
    string:
      name-list    compression_algorithms_client_to_server
      name-list    compression_algorithms_server_to_client

It is not clear for me from the formatting whether the first name-list is sent
by the client and the second by the server, or both lists are always included
in the value. I suspect it is the former, but can you please clarify?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Sentences like:
  Use of  Receivers MUST tolerate any sequence of bytes; including null bytes
  at any position; in an unknown extension's extension-value.
or
 In particular, applications MUST  tolerate any sequence of bytes; including
 null bytes at any position;  in an unknown extension's extension-value.

Use of punctuation is not my strongest point, but I am reasonably certain that
use of ";" is not correct here. I think you should use (). Otherwise these
sentences are reading as a list of 3 things, yet in both cases the 3rd is a
continuation of the 1st.

2) In Section 2.5:

 The relative order in which extensions appear in an
  EXT_INFO message MUST be ignored by default; but an extension MAY
  specify that the order matters for that extension, in a specific way.

Can you provide an example of why depending on order would be useful? This
potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be
less confusing if you used the latter consistently everywhere.

3) In 3.1:

  This extension is sent by the server, and contains a list of public
  key algorithms that the server is able to process as part of a
  "publickey" authentication request. If a client sends this extension,
  the server MAY ignore it, and MAY disconnect.

Why would the client disconnect when seeing this extension? Does it mean it is
broken?

Also, as the client can always disconnect at any point, why mentioning this
here?

  If a server does not send this extension, a client MUST NOT make any
  assumptions about the server's public key algorithm support, and MAY
  proceed with authentication requests using trial and error. Note that
  implementations are known to exist that apply authentication penalties
  if the client attempts to use an unexpected public key algorithm.

Can you elaborate on what do you mean by "authentication penalties" in this
context?


_______________________________________________
Curdle mailing list

--_----------=_150530832520629931-- From nobody Wed Sep 13 06:46: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 F1F07132D44; Wed, 13 Sep 2017 06:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 fum3n5DAJJye; Wed, 13 Sep 2017 06:46:47 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1122B13291C; Wed, 13 Sep 2017 06:46:46 -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=x5JaXEOZy2wfG0CiqOxQln0DIbxXUrTkwFY/Zhe9c14=; b=JOZcgTuDWIVpK0Cq+roAGsdmwuY7eeMLXs/xvlzwKSzuCWGtsFCMZVwwtBye9GWHV8MWwIOh4xbB+agjQB3npic8AH5ZHnT+IKa3sLNv6mCrUzLKkG2plumO6+Cq4WjYI9gKaEe9epq9je2svf17sV83ZCoEbPiIUiBGkgeRXmw= Received: from SN4PR0501CA0108.namprd05.prod.outlook.com (10.167.128.25) by MWHPR05MB3615.namprd05.prod.outlook.com (10.174.251.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 13:46:46 +0000 Received: from BY2NAM05FT054.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::209) by SN4PR0501CA0108.outlook.office365.com (2603:10b6:803:42::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4 via Frontend Transport; Wed, 13 Sep 2017 13:46:45 +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 BY2NAM05FT054.mail.protection.outlook.com (10.152.100.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Wed, 13 Sep 2017 13:46:45 +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, 13 Sep 2017 06:46:38 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v8DDkbjj022376; Wed, 13 Sep 2017 06:46:37 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 4302711494; Wed, 13 Sep 2017 06:46:37 -0700 (PDT) To: Alexey Melnikov CC: The IESG , , Daniel Migault , , In-Reply-To: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> Comments: In-reply-to: Alexey Melnikov message dated "Wed, 13 Sep 2017 04:46:10 -0700." From: "Mark D. Baushke" Date: Wed, 13 Sep 2017 06:46:37 -0700 Message-ID: <3253.1505310397@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)(346002)(366002)(376002)(39860400002)(2980300002)(199003)(189002)(6266002)(6246003)(2906002)(50986999)(76176999)(110136004)(54356999)(69596002)(47776003)(53416004)(81156014)(8936002)(8666007)(54906002)(55016002)(4326008)(5003940100001)(53936002)(81166006)(97736004)(7846003)(6392003)(86362001)(68736007)(77096006)(8676002)(558084003)(478600001)(316002)(229853002)(5660300001)(2950100002)(7126002)(230783001)(117636001)(6916009)(97876018)(50466002)(48376002)(7696004)(4743002)(305945005)(2810700001)(356003)(106466001)(189998001)(76506005)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3615; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT054; 1:LF8X4UrWJoB+178MiKCDsJCkJma7cD2z8KbTw2Qv8/H7QV/FQ6tvyYV+kt18XDWLP945p9ESdjeT9RZ2gPWY72swIAA2HyqqKYKnCtg0XwTNmv1JB6KCm99Ks+HOxIoo X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 80a7f907-70ad-4bce-9e3e-08d4faaddfd4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3615; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 3:zxPZ3dk2IpS4qhcB09WvdFrXwTppWCQLHXQocmd8sVIT59AYqdhl2Yr2exUHdtk8a/zbDUOQH5kjVmGA0EJjjWGz1xFv7xhF1UUd8t2+Z79/zgQxz/A0Mjvf0KsaxDp09u3FCq/G3RCC13zzo4xB83454BQd5+t98X65xhhNlnmEzchL78I+Fdwjic4hQYefen92NKrFY1FIigHSIZWT/BATV5uMgQWr5hYjguCq9EAvKg9tPvylIKffCMYsozmtuaEBhEC9BfSFKWhr8fkvVxcdhhrJ7ImzJYR3A8xkEipEwZyBHoahsBQkHZNmYBrqvxsKnG7SAxHaprUITENTsmsy2YjngZPV7e3vZ12MEcA=; 25:ZpnWLOoqmR5VTrzdpmoigQrxcZRYDyFduMgg2omqbCI9bqAlj+V8sL728YMgyJzIfZ3xU3EwtD+Cp5j9RD5DVxfBehOVkB2I4QNQ2JZ7hLzMIQr0LwrKi5YiQSeJF6pTlqIPaE61/4vO0CiXioAtFOHRJQibwWoMkTt9Vy1Va6kJh9sbAg0RLINpTIZ3lVzC+pNeoXegCFH7fw0Q95RBhvgynHtexL9mT3+zkmnwUwKqaMZT5n6T71ayoWXvH1TbA1/unspL0ZRvFfCIQiW2d1LTv155x5xcetG+tjSlLrfZkU32wWmj5lIhvJz0WalSmERPu7J0CDyYx6gBmYQA5g== X-MS-TrafficTypeDiagnostic: MWHPR05MB3615: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 31:he6LMhvpgFhzKMo9UxoVVecFJi3bPo3UvjCZT5r8bJRWp02JRkt+2NhKzptZO+S0M6pWnOAbnwmmV1TvX6xRjRwKUr0+0SZ8Wo+gTeyH4NP+LmqJDEqwTpoY1q8XAkEI3I3uIBzbnMWiLGWLKDiQyZrorVLybJJCBmrw+L8aPFCmen2f7znZ93xeHDhkDYbadZmzq5DpdGDMkukGktWSdc9Gf1Qx/nTevuwELARF9Cs=; 20:lbtQFzYVGtaQYEWtY1J3qvrlDAm0/g/HBudJj/BwswTfA82XtvTK+79k+bDq7LwmRcXaYYN3IvTsge3N2V5qtAGyDcqS3fTH9vUP6dXDHZ+IA+PuqY+ppeHUYyF1FMqK3AFIEUWx6cGYE4aQNBTzKorjlKuNMOZ3cYWL8V2CeXdt/HXHGjSmiYR5b9OYQXutTgQD9wkzHVCu0YM1rmf9IIbUvv/NMNwG0Ay7qMR8Pwu5anjJ/8WCKpC0SpM1lUOPV5ap1NFv95XVlQmrKTwRiiMiyr7ZhO/UhhKkoeJ3mSEY9oSUlN8HtfcdQmpaZg0oRdEv5BtEtWilRx/fSgMrGKco+K2pOlt5wwzyyiQ7CczgDR7R47omkDHNsDRpRGyjSkBVSstMsptwMZyIYnLe6+cOy0Gmdfir2XQPulCMgxFBAqq7TOTBlVImB0vJ2Z96ZHs03Bo3sw27E+vQK3Q695Vkr8AXdngrocVwsquxMm4pdX03kzkAIqGp0pj5igEY X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3615; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3615; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 4:AOWDHZz0mrfnrRP/NALTzfy4nqTa82kYH2D1qy5d6nOW5jGBWkrwxrXD+WErVt6WAYtdeIvlg+DXInAwV1yoV3fFm8YE8D6huyCR9mqvgGvfGy29ANqlvxLm4kaH8R8iDTENeprXS2xjMjFaRuRhCwVcq7aX3Vzi+00XiRSuta46P9TqSrNt2lOprduWZJGwDd3DzBcf0eV0MXAax0VaPutNX6hjwo2IuQNb8LhIdF8cp1ndDIgI060aklQT3ZG/ X-Forefront-PRVS: 042957ACD7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3615; 23:vfT+sa3igwc/c+cKuEszFIjRaN7HIfnB1StxY01uO?= =?us-ascii?Q?XmhMiJYKHf+OApTs6AOvuOYqpbPuhhZ0DjDBXuNRwUczFGlzx7JH2oPdBuli?= =?us-ascii?Q?ffOs9Vcp1gJm9/9zRKQeM0ZCeKKaGiCMpDNwrVonCBCkTvLlSrOFAvtpQAC7?= =?us-ascii?Q?QKjg6jrhhqIUPlG2nquvpgTb457ng4j5Jr/a2OeAgKcfp4HfNrLio/j8OMTJ?= =?us-ascii?Q?Yp2RG6aGtrmp24vEI3wUZUoYtn+XJCBkfAofPINgKLwnxNvmKBndOUJg0Lje?= =?us-ascii?Q?XaY395mRDEZm/FZNxOGR03StP/J60xqIJgOsv+8OKKf1Z1uIDg9FH6qBXWZe?= =?us-ascii?Q?MMoohM87fh/GlMgbzBdKiieZS1pAOuZjtLrrAjP8+qb9QjEHaaPg1Fr8Jyev?= =?us-ascii?Q?gdVNvnh0gmwjwReDr+nc15TZsUqq6SuECVgDtRmlZ+XZHC32l8iGsdvCLhTC?= =?us-ascii?Q?EZIp7BuwTQhUbt9/pSV89KZf7mO1kG7AzMM88uGzHrMsxd1Bwwnkilo/jsgi?= =?us-ascii?Q?UQMluNX3pyqPfIAKPn3tj928xX9KP3BMrcke5BKSb+mnfOhL0a+cdMHmhupd?= =?us-ascii?Q?5uXYdjsiD493ofODSugk5R/0FGOSS9NnPqu5qakuXa6IeCvKyd+I7afub1gE?= =?us-ascii?Q?j16LJZSQWCfUTqPKLJRxI3JsYveDDHQ7+yAFyddV9Sr2sm6JFGtFPU0OJo/4?= =?us-ascii?Q?jzEjbDEn8PD/GPC56q9xu11mUbNih096IEAqNXM8o8QGsLYy0CaFnEOc7vvD?= =?us-ascii?Q?lNWPYNKkq75nX9sNfDp3TgKzI6TaN+HxZLXvu5+mKkxoQvkhVWIyN1aa52vZ?= =?us-ascii?Q?Mz3J9pjl41V2rAxIY3aybvOrNmLhGu+R3Pns1Zl8UZ+pHXhxAXAxtrqLfU9a?= =?us-ascii?Q?OFap1BiJcwVH/q0ctM+0cybQ9SD+YxCmVX3+eX6rXTAX6KO9Ik4aPdmAm464?= =?us-ascii?Q?plwKFAkOK3RvZDxw12eCYEZzPnmgn9lFuDVWCGGpM690/HY0GaXuOtLVlu6M?= =?us-ascii?Q?DXlzUKJjJI81lzYtxKGVT0Nj9M6ChKe23uXAqJ5xcSOfxTKEu0KCXxAQbCTK?= =?us-ascii?Q?z3kY8R1Z8stk9W0c+xVz1tenPxt3LAE2d35UbV/6UeIeQiR30C+XJBCDXm/K?= =?us-ascii?Q?5lBm3SsEmg9O+QZTe5bAbs0i1KtxflFJJNLlklMVfhFMBgG0U7MScVWmwlIz?= =?us-ascii?Q?4bBWTvgFMXf8mdIX4yj+d2/rP03KzY/IEEBAJe7jGqzaO9Prjp3nazILzZbk?= =?us-ascii?Q?RKaW2YRBO9iT6tpukYvDd76f+xuh6nxNbmDvatT0hGy4KqY3Mukl7QyQPqyo?= =?us-ascii?Q?s3EFNs/ZMA4XuPuH1SF/KSbIEZOMVcy3dY8ZOKgI1FC?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3615; 6:Q8JQdvX7iAGQUfRXwE5LxYJCQT7nXP7Zpq8JUjgQ1VqC1YkC9N+LgDKI+0Ev3tA/1hZ0Lw9d9WFKl49huNPDOn6bV1I2yV6HtGA/HyvfKA6SuZSu307v/S2nDppugnxWwthGepgYXiqxRP2TvebNh4ZgP91vhOklT2lA3Hse3FaKbFGLA6KFblwjQ/ouZpPrU6Fs9Dp9ohx7C39fpP0uQKLrb833dkAqUbahi9hogDIgUR+d9LKCrDVqACqVD9PEszmBYgIXnFOzEzyPs+fp+C/jt9DxHrNfnV0PWy6Z1VSHRTC+ay/6DyhmzvjXGkvOG9zuaNxqgnCn4U1/HxzXjQ==; 5:gHiPze9nXin0J4+ytcLb16uSbo+DPlVDpQBaKwGFAcIWj33UBq3FvJ8dGTBWhPWEUcjnWOD3cMclh4a+9q9lBDRUXNMD9iXXprYTyE4AFNhpqE+dhLvqnD1YNPBS8ZJ/HiHQadQG44TaDhwD8Y0ucg==; 24:I2ckrhXNgzP0Z1v9UFrmT1hheH38PBCZudnZcybCG8qxXMicow4JHaXrB+KJ9Q9iqJUN72X8mxFCZzef7T7atvkaODaFJXu5wYrwAfJsrGw=; 7:EVuDKV5MDmxbX1y/uYTu0Pg6FQhUCQTV5ai0x/zBktha89P+/SyBFUWsmZs/05jl71SkUTlnXBVpvILfmmREb9Q/S0I+DKMLQWCYbE46LYaKJ9qUPLgdc5pxFu/tWd93Vhs4Ra2izKzTQ8p/B49Z4xjYnJngPfF9QO+13KD1Vwdu4a/N41qEwpsTnCuvyLZUr/6pjxKyF5T7bbuh+lksEz+r+2ovhgxkohq2PJJQuIk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 13:46:45.6997 (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: MWHPR05MB3615 Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 13:46:49 -0000 Alexey Melnikov writes: > Alexey Melnikov has entered the following ballot position for > draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection > > > RFC 6234 must be normative, as it is required to implement this document. Agreed. -- Mark From nobody Wed Sep 13 06:49: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 ED10F132F31; Wed, 13 Sep 2017 06:49:05 -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 aVvY_ohuto44; Wed, 13 Sep 2017 06:49:02 -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 155D1132D44; Wed, 13 Sep 2017 06:49:02 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 80so764139lfy.4; Wed, 13 Sep 2017 06:49: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=rDaMFxc5iukxPcEkxJ9wlgEdxNoVxK4bDTAlU8ab5e0=; b=DmJY7tLoaQkGncubqKUuFjRFuFHiXao+d1H/R5/MJt3D850C4zEHZ/6tF2C5PpG/yD mjYgLlvAvz3DZwdpjaFTnzxnoN61O2AN34723602kASLPa5AEYoIKBm6TaZdBLclKAco nqjnTHLB2pO00QoaMwGkIuSiWHnZDz89J2MMMvxo+vDRYLRAXH0SL3RF3ezCp/U06kMW Yh0OzveVy+5OxkTLm54s007ob6aeHDhQFkj6FKcrVyCKhysT8Q+ZD2wOIgzDgkLZmzEU PZXtFtsTmK/dRM26ZySL0e8HM17fZ1P0fJqF8gFixI9SlQTO37P6IoxhridT4oYYRnIx ghXA== 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=rDaMFxc5iukxPcEkxJ9wlgEdxNoVxK4bDTAlU8ab5e0=; b=Fa+w4G0YbKFdDJItdDOt9C4B9k/rFHUYvBUfPd7ktKr0TLtbRMfnEBtE5dEYmBPdWM uNbJcSw0epzx+DQVaSGIRCDjWVAKWh6CvYMhYiMbtx/gceOXqygKtKCBcwZw9edp09O8 6tODXAOFsVxyV37nnVVYfIDR0ye1BkBjkwN29lO3cSIr84FBqTcOA+7p8fL/RGjkvVRd kTjVw0lfzVynGpzandW89D3PGwXeMrfSiKQ0tAtv01wJ0XFY8NFlDxeRNrzerycswgsd BoXZjJSNQjGUp+fFngZvB0WRDzim625a4jtB40os6yM0y+fRpBn05zibgJXsnX5SbtXS YoyA== X-Gm-Message-State: AHPjjUgdNbw0evooHRlK0f1iG26pLhg8brCfrMr/QuBdIVjXJnG52sCy BjpHL7HVza429UruLOzLOosu6MSDcthR5FT6k7M= X-Google-Smtp-Source: AOwi7QAiCx9nyN9dQXD4PC1qF6slrEIeoisTI5S8qceubSswGWyGcegOubGik3fkQPsOJq4gh3AS2Agiosld38WIDKw= X-Received: by 10.25.18.195 with SMTP id 64mr5792125lfs.60.1505310540273; Wed, 13 Sep 2017 06:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Wed, 13 Sep 2017 06:48:59 -0700 (PDT) In-Reply-To: <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> From: denis bider Date: Wed, 13 Sep 2017 07:48:59 -0600 Message-ID: To: Alexey Melnikov Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a113fb8f8079a090559126c37" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 13:49:06 -0000 --001a113fb8f8079a090559126c37 Content-Type: text/plain; charset="UTF-8" > If you can list an example here for both the client side and the server side, that would be great. There is no difference between what the two send. Added a line to explain that as well. > capability negotiation frameworks and very few of them (at the moment > I can't think of any, actually) have dependencies on order Not sure if I understand you correctly, but SSH is completely dependent on order in algorithm lists (client algorithm order matters), and I believe so is TLS (server algorithm order matters). The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default, because the extensions are assumed to be independent. However, I see no reason to prevent it from becoming an algorithm list for some purposes, if the goals of some extensions overlap. Note that it takes zero effort to allow for this use; and requires writing unnecessary code to prevent. I'm not enthusiastic about writing unnecessary code to prevent a particular type of use, just to prevent people doing something in the future. The idea, honestly, seems stupid. > My gut feeling is that you will never need this, so I wanted to know if you actually > can provide an example that depends on order. It would have to be two or more extensions with overlapping goals. For example: 1. Extension A attempts to address situation X. 2. Extension A is flawed in situation Y, which bothers some people. 3. Extension B is developed to addresses situations X+Y. However, being more complete, it is much more complex than Extension A. Past experience shows that there will be existing servers which will only do Extension A well. They might implement B, but it will be a hack job. 4. Therefore, Extension B specifies itself as a potential replacement for Extension A, but allows servers to signal which one they prefer by controlling the order in which the extensions appear. If both extensions are advertised by both parties, then Extension B is used IF it is listed first by the server. Otherwise, if Extension A is listed first, it is used. Common example - Extension A favored by Linux servers, Extension B favored by everyone else. The story of SFTP. > I think explaining this in the document would be useful. > "Penalties" sounds a bit vague. Added footnote to explain. denis On Wed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov wrote: > On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote: > > > It is not clear for me from the formatting whether the first > > name-list is sent by the client and the second by the server, > > or both lists are always included in the value. I suspect it > > is the former, but can you please clarify? > > SSH negotiates compression, integrity, and encryption algorithms > separately for each direction. Both lists are sent by both parties. Not > just here, but also in KEXINIT. > > This is used rarely in practice, but this draft keeps to the same > practice, so as not to bundle a reduction of functionality (i.e. requiring > same compression for both directions) in the same package as an extension > (i.e. providing a mechanism for delayed activation of compression). > > The next draft will include an example of encoding, as suggested by Adam. > This should make things clearer, even for readers unfamiliar with SSH. > > Yes, I think this will help. If you can list an example here for both the > client side and the server side, that would be great. > > > > 1) Sentences like: > > Use of Receivers MUST tolerate any sequence of bytes; including > > null bytes at any position; in an unknown extension's extension-value. > > Reads fine to me. Still, I changed these to use dashes. > > > > Can you provide an example of why depending on order > > would be useful? This potentially makes it harder to implement. > > It is the nature of an extension mechanism that it intends to be open to > unforeseen circumstances. If we could come up with examples for all > possible future uses, extensions would not be required. > > For this reason, I would prefer if you can demonstrate how allowing for > this possibility makes anything harder to implement. In my implementation > experience, it doesn't. > > I implemented multiple capability negotiation frameworks and very few of > them (at the moment I can't think of any, actually) have dependencies on > order. Dealing with one element at a time seems a bit simpler. > > My gut feeling is that you will never need this, so I wanted to know if > you actually can provide an example that depends on order. > > > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. > > It would be less confusing if you used the latter consistently > everywhere. > > This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, > NEWCOMPRESS, and USERAUTH_SUCCESS. > > OK, I changed this to use the SSH_MSG_ prefix always. > > Thank you. > > > > This extension is sent by the server, and contains a list of public > > key algorithms that the server is able to process as part of a > > "publickey" authentication request. If a client sends this extension, > > the server MAY ignore it, and MAY disconnect. > > > > Why would the client disconnect when seeing this extension? Does it mean > it is > > broken? > > > > Also, as the client can always disconnect at any point, why mentioning > this > > here? > > I believe you have misread the text in this case. It should be clear from > the above quoted snippet. > > Oh, do you mean that this is never supposed to be sent by the client? In > this case, yes, I misread it. Never mind. > > > > Can you elaborate on what do you mean by "authentication penalties" > > in this context? > > SSH servers commonly implement some way of locking out or throttling IP > addresses that make frequent login attempts, so as to deter brute force > password guessing, username guessing, and similar undesired behaviors. > > Some servers apply such penalties to clients that attempt to use an > unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the > client's IP address being locked out. > > The "server-sig-algs" extension provides a way for the client to know that > the server supports e.g. "rsa-sha2-256" before it attempts to use it, to > avoid a potential IP lockout. > > I think explaining this in the document would be useful. "Penalties" > sounds a bit vague. > > On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov > wrote: > > Alexey Melnikov has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is generally a good and useful document. I have some minor comments I > would like to discuss: > > 3.2. "delay-compression" > > This extension MAY be sent by both parties as follows: > > string "delay-compression" > string: > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > > It is not clear for me from the formatting whether the first name-list is > sent > by the client and the second by the server, or both lists are always > included > in the value. I suspect it is the former, but can you please clarify? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) Sentences like: > Use of Receivers MUST tolerate any sequence of bytes; including null > bytes > at any position; in an unknown extension's extension-value. > or > In particular, applications MUST tolerate any sequence of bytes; > including > null bytes at any position; in an unknown extension's extension-value. > > Use of punctuation is not my strongest point, but I am reasonably certain > that > use of ";" is not correct here. I think you should use (). Otherwise these > sentences are reading as a list of 3 things, yet in both cases the 3rd is a > continuation of the 1st. > > 2) In Section 2.5: > > The relative order in which extensions appear in an > EXT_INFO message MUST be ignored by default; but an extension MAY > specify that the order matters for that extension, in a specific way. > > Can you provide an example of why depending on order would be useful? This > potentially makes it harder to implement. > > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be > less confusing if you used the latter consistently everywhere. > > 3) In 3.1: > > This extension is sent by the server, and contains a list of public > key algorithms that the server is able to process as part of a > "publickey" authentication request. If a client sends this extension, > the server MAY ignore it, and MAY disconnect. > > Why would the client disconnect when seeing this extension? Does it mean > it is > broken? > > Also, as the client can always disconnect at any point, why mentioning this > here? > > If a server does not send this extension, a client MUST NOT make any > assumptions about the server's public key algorithm support, and MAY > proceed with authentication requests using trial and error. Note that > implementations are known to exist that apply authentication penalties > if the client attempts to use an unexpected public key algorithm. > > Can you elaborate on what do you mean by "authentication penalties" in this > context? > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > --001a113fb8f8079a090559126c37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0If you can list= an example here for both the client side and the server side, that would b= e great.

= There is no difference between what the tw= o send. Added a line to explain that as well.


>=C2=A0<= span style=3D"font-size:12.8px">capability negotiation frameworks and very = few of them (at the moment
> I can't think of any, actually) have dependencies on order

Not sure if I understand you correctly, but SSH is= completely dependent on order in algorithm lists (client algorithm order m= atters), and I believe so is TLS (server algorithm order matters).

The list of extensions in SSH_MSG_EXT_INFO is order a= gnostic by default, because the extensions are assumed to be independent. H= owever, I see no reason to prevent it from becoming an algorithm list for s= ome purposes, if the goals of some extensions overlap.

Note that it takes zero effort to allow for this use; and require= s writing unnecessary code to prevent.

I'= m not enthusiastic about writing unnecessary code to prevent a particular t= ype of use, just to prevent people doing something in the future. The idea,= honestly, seems stupid.
=

> My gut feeling is that you will never need thi= s, so I wanted to know if you actually
> can provide an example that depends on order.

It would have to be two or more extensions with overl= apping goals. For example:

1. Extension A att= empts to address situation X.

2. Extension A = is flawed in situation Y, which bothers some people.

3. Extension B is developed to addresses situations X+Y. However, b= eing more complete, it is much more complex than Extension A. Past experien= ce shows that there will be existing servers which will only do Extension A= well. They might implement B, but it will be a hack job.
=
4. Therefore, Extension B specifies itself as a potential repl= acement for Extension A, but allows servers to signal which one they prefer= by controlling the order in which the extensions appear. If both extension= s are advertised by both parties, then Extension B is used IF it is listed = first by the server. Otherwise, if Extension A is listed first, it is used.=

Common example - Extension A favored by Linu= x servers, Extension B favored by everyone else. The story of SFTP.<= /div>


> I think explaining this in = the document would be useful.
> "Penalties" sounds a bit vague.

Added footnote to explain.

denis




On W= ed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm= > wrote:
On Wed, Sep 13, 2017, at 01:56 PM, denis bider w= rote:
>=C2=A0It is not clear for me= from the formatting whether the first
= > name-list is sent=C2=A0by the client and the second by the server,
= > or both lists are always included=C2=A0in the value. I suspect it
= > is the former, but can you please clarify?
=
= SSH negotiates compression, integrity, and encryption algorithms separately= for each direction. Both lists are sent by both parties. Not just here, bu= t also in KEXINIT.
=
= This is used rarely in practice, but this draft keeps to the same practice,= so as not to bundle a reduction of functionality (i.e. requiring same comp= ression for both directions) in the same package as an extension (i.e. prov= iding a mechanism for delayed activation of compression).
=
= The next draft will include an example of encoding, as suggested by Adam. T= his should make things clearer, even for readers unfamiliar with SSH.
Yes, I think this will help. If you can list an ex= ample here for both the client side and the server side, that would be grea= t.


= >=C2=A01) Sentences like:
= > Use of=C2=A0 Receivers MUST tolerate any sequence of bytes; including<= /span>
> null bytes=C2=A0at any position; in an unknown extension's = extension-value.
=
= Reads fine to me. Still, I changed these to use dashes.
=

= >=C2=A0Can you provide an example of why depending on order
=
= > would be useful? This=C2=A0potentially makes it harder to implement.=
=
= It is the nature of an extension mechanism that it intends to be open to un= foreseen circumstances. If we could come up with examples for all possible = future uses, extensions would not be required.
=
= For this reason, I would prefer if you can demonstrate how allowing for thi= s possibility makes anything harder to implement. In my implementation expe= rience, it doesn't.
I implemented multiple capability negotiation fram= eworks and very few of them (at the moment I can't think of any, actual= ly) have dependencies on order. Dealing with one element at a time seems a = bit simpler.

My gut feeling is that you will never need this, so I wanted to know i= f you actually can provide an example that depends on order.

>=C2=A0In several places= you use EXT_INFO instead of SSH_MSG_EXT_INFO.
= > It would be=C2=A0less confusing if you used the latter consistently = everywhere.
=
= This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, N= EWCOMPRESS, and USERAUTH_SUCCESS.
=
= OK, I changed this to use the SSH_MSG_ prefix always.
Thank you.


= >=C2=A0=C2=A0 This extension is sent by the server, and contains a list = of public
= > =C2=A0 key algorithms that the server is able to process as part of a<= /span>
= > =C2=A0 "publickey" authentication request. If a client sends= this extension,
= > =C2=A0 the server MAY ignore it, and MAY disconnect.
= >
= > Why would the client disconnect when seeing this extension? Does it me= an it is
= > broken?
>=C2=A0
= > Also, as the client can always disconnect at any point, why mentioning= this
= > here?
=
= I believe you have misread the text in this case. It should be clear from t= he above quoted snippet.
Oh, do you mean that this is never supposed to be = sent by the client? In this case, yes, I misread it. Never mind.
<= span class=3D"">


= >=C2=A0Can you elaborate on what do you mean by "authentication p= enalties"
= > in this=C2=A0context?

= SSH servers commonly implement some way of locking out or throttling IP add= resses that make frequent login attempts, so as to deter brute force passwo= rd guessing, username guessing, and similar undesired behaviors.
=
=
= Some servers apply such penalties to clients that attempt to use an unknown= public key algorithm (e.g. "rsa-sha2-256"). This can result in t= he client's IP address being locked out.
=
= The "server-sig-algs" extension provides a way for the client to = know that the server supports e.g. "rsa-sha2-256" before it attem= pts to use it, to avoid a potential IP lockout.
I think explaining this in the document would be u= seful. "Penalties" sounds a bit vague.

On Wed, Sep 13, 2017= at 6:00 AM, Alexey Melnikov <aamelnikov@fastmail.fm> w= rote:
Alexey Melnikov has entered the = following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all=
email addresses included in the To and CC lines. (Feel free to cut th= is
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a good and useful document. I have some minor comme= nts I
would like to discuss:

3.2.=C2=A0 "delay-compression"

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

=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-com= pression"
=C2=A0 =C2=A0 string:
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_cl= ient_to_server
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_se= rver_to_client

It is not clear for me from the formatting whether the first name-lis= t is sent
by the client and the second by the server, or both lists are always = included
in the value. I suspect it is the former, but can you please clarify?=


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Sentences like:
=C2=A0 Use of=C2=A0 Receivers MUST tolerate any sequence of bytes; in= cluding null bytes
=C2=A0 at any position; in an unknown extension's extension-value= .
or
=C2=A0In particular, applications MUST=C2=A0 tolerate any sequence of= bytes; including
=C2=A0null bytes at any position;=C2=A0 in an unknown extension's= extension-value.

Use of punctuation is not my strongest point, but I am reasonably cer= tain that
use of ";" is not correct here. I think you should use (). = Otherwise these
sentences are reading as a list of 3 things, yet in both cases the 3r= d is a
continuation of the 1st.

2) In Section 2.5:

=C2=A0The relative order in which extensions appear in an
=C2=A0 EXT_INFO message MUST be ignored by default; but an extension = MAY
=C2=A0 specify that the order matters for that extension, in a specif= ic way.

Can you provide an example of why depending on order would be useful?= This
potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It wo= uld be
less confusing if you used the latter consistently everywhere.

3) In 3.1:

=C2=A0 This extension is sent by the server, and contains a list of p= ublic
=C2=A0 key algorithms that the server is able to process as part of a=
=C2=A0 "publickey" authentication request. If a client send= s this extension,
=C2=A0 the server MAY ignore it, and MAY disconnect.

Why would the client disconnect when seeing this extension? Does it m= ean it is
broken?

Also, as the client can always disconnect at any point, why mentionin= g this
here?

=C2=A0 If a server does not send this extension, a client MUST NOT ma= ke any
=C2=A0 assumptions about the server's public key algorithm suppor= t, and MAY
=C2=A0 proceed with authentication requests using trial and error. No= te that
=C2=A0 implementations are known to exist that apply authentication p= enalties
=C2=A0 if the client attempts to use an unexpected public key algorit= hm.

Can you elaborate on what do you mean by "authentication penalti= es" in this
context?


_______________________________________________
Curdle mailing list


--001a113fb8f8079a090559126c37-- From nobody Wed Sep 13 07:41:44 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D60132949; Wed, 13 Sep 2017 07:41:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares To: Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-dh-group-exchange.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150531370238.30451.687387668032813578@ietfa.amsl.com> Date: Wed, 13 Sep 2017 07:41:42 -0700 Archived-At: Subject: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-dh-group-exchange-05 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, 13 Sep 2017 14:41:42 -0000 Reviewer: Susan Hares Review result: Has Nits This document provides a clear description of the change in minimum modules size. On editorial comment, this document does not indicate whether it is wise for the operations system to log a report if it receives a less than 2048 bits. Would this enhance security or provide DoS attack surface. If logging creates a DoS surface, it would be good to include this as operational advice. From nobody Wed Sep 13 09:34: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 B499C133086; Wed, 13 Sep 2017 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-XeERPdMhxn; Wed, 13 Sep 2017 09:34:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E4C191338E3; Wed, 13 Sep 2017 09:34:33 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8DGYQLC027612 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 11:34:27 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: denis bider Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org References: <150525503378.30416.5679611796140295482.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 13 Sep 2017 11:34:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] Adam Roach's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 16:34:36 -0000 On 9/13/17 12:34 AM, denis bider wrote: > Comment 1: Good point. Example is useful. Will add example. Thanks. I think an example would be very useful as an adjunct to an explanation. If there is some other place this "lists inside strings" construct is used, please point to it. Otherwise, please include one or two sentences that explain the intended structure. /a From nobody Wed Sep 13 09:58: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 B023D1321B6; Wed, 13 Sep 2017 09:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150532187371.30557.3667637086815234451.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 09:57:53 -0700 Archived-At: Subject: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) 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, 13 Sep 2017 16:57:54 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-curdle-ssh-modp-dh-sha2-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. I agree with Alexey's comment on the normative reference and just have a tiny nit for the introduction: I suggest you remove the word recent since the reference on SHA-1 is 6 years old: s/Due to recent security concerns with SHA-1 [RFC6194]/Due to security concerns with SHA-1 [RFC6194]/ From nobody Wed Sep 13 10:06: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 BD6CD132D49; Wed, 13 Sep 2017 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 jWhONnw5P3ya; Wed, 13 Sep 2017 10:06:54 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0112.outbound.protection.outlook.com [104.47.34.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD811252BA; Wed, 13 Sep 2017 10:06:54 -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=kpZR8Gc/K5MXZyVB2MroWgVBhgbhQ+nLHacA3nknO5w=; b=DUIpw2StE2mjb1KqCghLcHMBy93KWBMRJe93AdJN31CoHzmtKG7tyLzEOQqUpXmr5ljyY9O8pbnqPxRO/cJnUeOArxDhHwhcDVk3r5nEW3UFx2PYfnFFMUbw2TRVCzODy7OferhNqxPJ0TKmD+M/aHEpiiAQJcJGTTqJEUY1FUU= Received: from DM5PR05CA0013.namprd05.prod.outlook.com (10.173.226.23) by DM5PR05MB3609.namprd05.prod.outlook.com (10.174.242.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 17:06:53 +0000 Received: from DM3NAM05FT021.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by DM5PR05CA0013.outlook.office365.com (2603:10b6:3:d4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.56.4 via Frontend Transport; Wed, 13 Sep 2017 17:06:53 +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 DM3NAM05FT021.mail.protection.outlook.com (10.152.98.130) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Wed, 13 Sep 2017 17:06:53 +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, 13 Sep 2017 10:06:14 -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 v8DH6Da5000566; Wed, 13 Sep 2017 10:06:13 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 1FD4211446; Wed, 13 Sep 2017 10:06:13 -0700 (PDT) To: Kathleen Moriarty CC: The IESG , , , , In-Reply-To: <150532187371.30557.3667637086815234451.idtracker@ietfa.amsl.com> References: <150532187371.30557.3667637086815234451.idtracker@ietfa.amsl.com> Comments: In-reply-to: Kathleen Moriarty message dated "Wed, 13 Sep 2017 09:57:53 -0700." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU Sender: 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)(346002)(39860400002)(376002)(2980300002)(199003)(189002)(50226002)(86362001)(39060400002)(8676002)(68736007)(6246003)(50986999)(478600001)(4326008)(305945005)(76176999)(110136004)(105596002)(106466001)(97736004)(50466002)(316002)(5003940100001)(47776003)(5660300001)(7696004)(2950100002)(76506005)(2906002)(7126002)(48376002)(230783001)(6392003)(7846003)(77096006)(55016002)(6916009)(356003)(54906002)(229853002)(189998001)(69596002)(8936002)(4743002)(2810700001)(97876018)(81166006)(81156014)(53936002)(6266002)(117636001)(53416004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3609; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT021; 1:/wwOwnn9zIACbjLhsL0w90KZA/Ji/6fZkD4JCHLzvhUNt3D/ytsAcW1Nabigmc5FLMGhd4Ql5BpnlUsQo3rnIqU/RNw0BodycCXDOSroWCk2BXhIccOG6XAKEXWJfCzD X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7316a044-398d-4c3e-df20-08d4fac9d505 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR05MB3609; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 3:edtRB20ZBx5/hClTaDhi54+zDCEYIlgiZscKCUYNkkXHVWnDfRSmLacfQLYN823MTdHHuCS8YTfwNKiSKCxYV9tfUdsvl1NX+kJg9jZMrCpWSGvLS4M10JLWaVlMhOeg+XEfLOoO/9gjBLDRvazz4tb+cfm/YP8cImgX6n9lgmCdsgenjoeSn+2e29ac1u5obJjQSF/txlKCOtiGNFnkrYjMoqVVYntURw2j3bhjLuJCAhQChQikkc9SwX5PxaKw8FfzU4zWxZdGToojP1xWGaGWNDSzgdYKaKu6tn72Gf76gQNNxhl7EMb/cugM8y90HBjUh7k+XLPHomDzwISTUQuYmz+TTjoAT+eD9lNB0uY=; 25:G1tdgD4i7yUJ8atq1akaqXXtse2uqSDCRK7MCnKqsc5bRL9zVYx9Ho3WTdVZHGxIbH9cRJkhCRZ1zTtcR1OyWRVwvWDg+Jf2zHo9bN8W3g2meIvAcYn8+qfeCchyK4RfVwYk4oz42xEx7Y1tLaEB51mRqIsew0pVDPV/zgSP+9wFpaNHQOO1ZIN1YeJSbUmVLMtJkP1lHIVbjpofQ33vk1PWH9w4DGxDJwxcI5jFtXas/h5zYeZZFjwbcXBCjvZZRI36+v5X3LOOir3EhGAP/dRH6rB2Dqk2zssWT2DtkXdBWKHlVOaattOnzHg6qQ9jUdy4tXx0KAw9kVCvJB7wXQ== X-MS-TrafficTypeDiagnostic: DM5PR05MB3609: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 31:EDwVDvrCWm4gikgFn/eBj3Qi704aRC7UJTCi/NmMGsyVzo657tQqZP0yA/YYVKYyDuLu9HMCgkZCjq0TGDVa42KSBXK/6iC8JujdVVrFFgz7dAr2OzUB4oOS4h9C+3eN4q3hPbjlsrF+XTTqq6d5itx0YC7mn3cKjOsNgiKXfqTZ2vdTEogwVIBI+EN5SIQk4s1QxeqGRXjrvLsk1x0Tuh/gCEIMBIxCG+IRBvcEh4I=; 20:gI+OPaWpsMbQaDGvGpydkLX4SWGIjZ0xqcGyb9/damA6V7nXh/sBclcEorwFw8+TEexRAftQLFlM3XovnXrRDafsol6sK9OR9FmTHxypQMQdCpX/WnGeLCHfeH5Px0/r8v6MfzxQ1Cx/CpxgdJivKJjrYVw5/I6T7rwnHi+XihY+HWK0X0s0dNGzciKPtDo+eg4Q6NPJblPxy6d5Ob8zQQTg99oXZWbJs2id1jHCYKOJwL1Xz+J2hfDTqoKlY1CqDW9pUEbXgfGE4bCrLvP1j9SFOEx/dpz5vqA9bJ2nEZ8A4BxX3NA35gJoHIoCXOWdVGi6DGX0/b11aSQkKXrJFluZxUotImPfFNVJWXS9UTHkmmOWCSgQINQD5HB0f8xRr2Q1//V6pPb355O+IGx79QYq4XuUOg2SgV8zxdTzse5xH3OX0rdtz5S9O+BC/5o+JON93x3rmqmrk2tDP7AV9Pp3dLUoD1UTTWGdN7QogrBhYR4ZEFcBf/dCmuY2aFuS X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3609; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3609; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 4:Z0XzsI6qu2c3tZgrqGdfvi6dAi1n4+VZ0sRuMKHfdvGZzJon2DdtcufW7ul9U8W8iyyhptPHwzuyBck/cLVue95bm+VbOT2zA057GWgYxIydoVf+Yi7ML69DUrzNa/2wxGMsFf5IhNVAX2b73D+PGpZyWnfYnG4hgTpPH9H4+RGnDlFn4mffVYrwBhS3vGKobETz/3UZcYUIVM6VgRijwbVTBowYIwCHQvcF/Ky2Akit3nyJa495gBzk8fFBSLUQoyZVdLjH8xltNPBR6vN9BBh7qIOH92XYlR2mEqotIQY= X-Forefront-PRVS: 042957ACD7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3609; 23:s26f/GHfF5GdGZECCjxhPbfddPPnRvdyhzTEtQBw8?= =?us-ascii?Q?cURiByX8UI0eIxRS8jtQPZglP7Nn4alhBnJvtuvM17NRXir9n8rcKC75rTEq?= =?us-ascii?Q?PIOB/h8om6olu38IkQbo9+fnOxmos/EfKVlusAUqsaCEW9VztYr0Zc/cLAAA?= =?us-ascii?Q?+o2jCbuOk+DxqaTKu0Twlwz9UIw20N/XTeYJ2BthDQzGkhw1nw3NZgWRt5a4?= =?us-ascii?Q?lLLQJXARdmM59laybCkoFpb8rHJNd1haCDe4n3/bjuDukpxcvEUPAwE0Etqm?= =?us-ascii?Q?Ha/A2tnkeMXsKTd+xxTBroFvYSA4QullEMsmGhaggg5uCBIN6DHd9eaTz5xS?= =?us-ascii?Q?wdA3dDGL+ODTXX+W5lLtq4ebWVTAIulORz7ZzLSrFMcXHvOvSGbXnZ5T6Jje?= =?us-ascii?Q?zHJOtsu68cA8vxIFpaz8MaPakZKjXtLk+teCgS5ffMQPXFeeTiVotLndx5z9?= =?us-ascii?Q?N6RlGTO8PN6LaXEjOcNNQTI+6d9MBQsfJfmZdKj3nI76SL4XGfbRtH6SZ0Og?= =?us-ascii?Q?Ejb3mY2kL0OmByGE+dEyuy3ksGq6Jxx9LY4x4Tz/B6xghJ8BcyJGvhl9b0MD?= =?us-ascii?Q?z8HHyEaDWLCDvoGbpiHtXSSrqp9rBVa0XHpoiGdNsZLGQSeleNxkFZH4SSeU?= =?us-ascii?Q?TOMKZdHz6oqbmdAWYBLVqLgDGySi9O5OWoTLJFt17dE72TbtsyVcH0UJtWhA?= =?us-ascii?Q?oY37MiEY+cjkBTZ3QiizaTpiFFISScsyetBeiryaSOn8LByR8UicNgexfaqg?= =?us-ascii?Q?EhK36ATUQuSKEHz1toZSFCJghMda832rAl0TZlLfPpne5nhNkoqmq8/rqqal?= =?us-ascii?Q?Dsk91mje9Cb1pfsEmWvMGRLncVOgPFISk/u/EMTFO5o5mOHC86Za0BXe96ZV?= =?us-ascii?Q?18LavXBHJWuw03oMBJVihV1cocq8rLddhZuQCkpFS1np+rm2le2r1gHDzK1K?= =?us-ascii?Q?fwlS7vLvMn6dK70jWE9cIffCUOxLg804DDfLZMkMFlIrVnh5vAdUyAQWQrH5?= =?us-ascii?Q?dnkRSwXvnDiRswmg2yUxPF6ycHOet4MW5JYB+yqmV5UxqbG/licc68WWFnhu?= =?us-ascii?Q?jZD3+QM1s4EkbBpI13vKsct6MgVIK0x7gf8G2GTwN9cN5Bc2ko45XdAlyuAw?= =?us-ascii?Q?ppRZIcAyA92P3+kH1t2kPxT7Aa0FSJmUcoanjeF34YWcs5JOwiQjJXYj8LyW?= =?us-ascii?Q?tUB1UejXgijEyYHr/bW8kqvDvOazVVY97Rd+eyfY8fLnaG9vya1Hui2aYL1k?= =?us-ascii?Q?U7BGaNfO269zexmBTyyzH+dIwoVPcrd124ZLAhGdBEFLy9cqkfwwZY/s/gc2?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 6:2mAG1qMOjOG8bKxAUIy6mZucd83jWe2R/6gZzKswsQZXV38YdV0qW5f7zhmfhTGpsp2VsYyfMwQlwyFPT/9+FbEBHHuaMofuzuLMn5qm4Mwg+j337/8dlyQcmQSZkqGPXmmgO+1ZH1/kKEudyqWhvBuXmvVhLonEuDOoLM3U1G89bKLxSlCS5LQKZPCbXiBxP2tF+q0M/DMUaVfZk1h2qB9ZlV5UpgNUht2lPLAR52Iyi6cp0c0LxA1vTMpgn8+J6DwdMPVOH7cTD+bMRvJwKwxm5CqeJf83D8RaNi+nlaGD76wyA+ekj0WtgeICSJHgAQ16i6xe4rSBjKc0uqv/wA==; 5:1xlGnGgNOAnsNzZcqIJQoEuNsf67VcW5+yLCDaPafByskGw/bdV0m577lrD1hVHhIV1RtL1apLJ08UE+tQ3m07GM34Y+48bAPS9dIALmxC6tCKLmVZxsNFhrVGWfsCvOBFHtK0eqs4zAeTCUAS2b8Q==; 24:Dnh7ETGEAGQY5/ikFpCYdngbbQy4f7FiwHmBjgYA87mocA6nrGfUl9e3W8T/+BbfwNc3nqTz3Z7Gfck1FbgVk4YphjWZEGyG3wB9x/uclGo=; 7:ac9bTf0PSYOCFyvmjRKLOvzgsxiUd5tS1ppvawqRX7Vnnw43P0+rCfkbNnd1XZGtNXmurPpvvb/42Rw/gVQePFfeESmL0isRlx0V4rVD8qBoRxICdNtgTofiQbgqvoK/v7yJOSsagb6pMf0f1tX0X0+R9VdVetjxzkDPai0XEIY8ku/C1qTbds8JuHYCBXNwS8YJFTnOYXz8dJpp87y7vU19fvSmPuKZxvsWLRN5MDk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 17:06:53.2416 (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: DM5PR05MB3609 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 17:06:56 -0000 Kathleen Moriarty writes: > Thanks for your work on this draft. I agree with Alexey's comment on the > normative reference and just have a tiny nit for the introduction: Yes, I will do that. > I suggest you remove the word recent since the reference on SHA-1 is 6 years > old: s/Due to recent security concerns with SHA-1 [RFC6194]/Due to security > concerns with SHA-1 [RFC6194]/ Good point. I will adopt this change. -- Mark From nobody Wed Sep 13 10:19: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 424E8133082; Wed, 13 Sep 2017 10:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 9JoN5WXn-cGD; Wed, 13 Sep 2017 10:19:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3D676132CE9; Wed, 13 Sep 2017 10:19:09 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8DHJ4c4035227 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 12:19:05 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "Mark D. Baushke" Cc: curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, curdle-chairs@ietf.org, The IESG References: <150524680948.17880.11498685853024501328.idtracker@ietfa.amsl.com> <82639.1505253104@eng-mail01.juniper.net> From: Adam Roach Message-ID: <467f4e12-ce68-d8e1-6e74-07f1bdb1dffc@nostrum.com> Date: Wed, 13 Sep 2017 12:19:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <82639.1505253104@eng-mail01.juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 17:19:10 -0000 Thanks! These all look good to me. /a On 9/12/17 4:51 PM, Mark D. Baushke wrote: > Adam Roach writes: > >> Section 1, paragraph 2: >> >> New MODP groups are being >> introduced starting with the MODP 3072-bit group 15 all use SHA512 as >> the hash algorithm. >> >> I can't parse this. Should there be a sentence break between "15" and "all"? > Yes. There should be a period after 15 and 'all' should be 'All' > >> I was surprised to find section 4 here; in part because it isn't >> related to the addition of new algorithms, but mostly because it's not >> mentioned in the abstract or the introduction. Please add mention of >> this erratum correction to both sections. > Thank you. > > I will change 'This document updates RFC 4253.' to > > 'This document updates RFC 4253 including an errata for checking the > Peer's DH Public Key.' > > in the abstract. > > I then added > > Section 3 of the [RFC4253] contains a small errata for checking > the Peer's DH Public key. Section 4 of this document provides the > correction. > > as a new paragraph under the Overview and Rationale. > >> I'm pretty sure RFC6234 needs to be normative. > Okay, that is an easy change to make. > > -- Mark > From nobody Wed Sep 13 10:38: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 0A6BE133075; Wed, 13 Sep 2017 10:38:43 -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 JX75MrBhyotP; Wed, 13 Sep 2017 10:38:41 -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 CCEA91320D9; Wed, 13 Sep 2017 10:38:40 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v72so2127367ywa.3; Wed, 13 Sep 2017 10:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9USCVkfubXJKK+4pkjd1b4z4UczuYsnkApkIXDVJRrA=; b=h/JSiom7xagDMy9COMXMtPK6XaynaHx2m7Mt0y202zPUjr58OVpzvunVf23KiDlhMh +AW8GQccLQ9Txx7nSnYufZzd4NBiFN4wyL5y6+QvLM75HNh2i1Cxigxx4pN9VtD5u7xK vxyLhT0zopVK82+yYPvfbOgWKEIxoMmqm9mpgEm8FGCDIRFdI5IbOv9zwwbSVuhA/Isa e9cvA/ueAccCZyW6BgFkblWtka/ZIncdYVRO2A8e2XpOP/bP+i9oeaKcSWp0+05L5aO7 fNS4QeUzTNlfJBOaog85zQF5MnZJHFBvNw8wCJ8JsxY09/qXIUHj+ZZ9GB/rZjmHIPvX FyWw== 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=9USCVkfubXJKK+4pkjd1b4z4UczuYsnkApkIXDVJRrA=; b=pfzQgXvlHM/dS/GNtrLbADSPxuWDYuYW2xpB/CNb6/d/BHrl8SD5Ban8BN+LoW/qeU +ZtgBYqdUcT8dJm8I1zVDPA1o1GP5qymxN4rcxEms9x6kNBq5pkp2KYTEbyuxb9xdPL1 B7ijWreRLj/VVAFmtvLOZFqA5ZiwtdKM9pxgRTkYZTs2xzEoBgOxY4VIt94cYieoBOvL uwmKrWvNwkhItoxdRUbLYs6mVdY0X2eGy9G0U3sY4IsT3Qew8KBw97kKZahRn089bquy nW9ZNURtciTtQrufGVlTFNJv694IAI8ex0i+P4/tIEXbxqdnCapJ/PIBr/ZICWFvEyDt 2J6g== X-Gm-Message-State: AHPjjUg6+odhAvmqQhoRtOxniMsx5sBZJ35xHKJ08P00YIqo74kmyrKp KPj9IfwhN+/U8eeI6TOHg8vq9I9kiwa442+j9mA= X-Google-Smtp-Source: ADKCNb626llkx2INHW4yjboI5Ik0T+oVxd9qWWZFEsrvWu+ls2EFMIex44oV+iEVOvWLQxzSTrkWF3JAP5F6xVkW/qc= X-Received: by 10.37.162.193 with SMTP id c1mr15432283ybn.66.1505324319857; Wed, 13 Sep 2017 10:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Wed, 13 Sep 2017 10:38:39 -0700 (PDT) In-Reply-To: References: <150524144548.17894.106479337730195058.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 13 Sep 2017 12:38:39 -0500 Message-ID: To: denis bider Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="089e0828ff1c5b6100055915a188" Archived-At: Subject: Re: [Curdle] Spencer Dawkins' Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Sep 2017 17:38:43 -0000 --089e0828ff1c5b6100055915a188 Content-Type: text/plain; charset="UTF-8" Hi, Denis, On Wed, Sep 13, 2017 at 1:11 AM, denis bider wrote: > Hello, > > replies below: > > > > In this text, > > > > Implementations MUST NOT send an incorrect indicator name for their > > role. Implementations MAY disconnect if the counter-party sends an > > incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being > > negotiated as a key exchange method, the parties MUST disconnect. > > > > why would a party that doen't support this extention disconnect? > > This language clarifies a corner case that's not expected to happen. > Algorithm negotiation in SSH works like this: > > For each algorithm type (e.g. key exchange) and direction (for some > algorithm types, e.g. encryption): > > - Server sends a comma-separated namelist of algorithm names in the > initial KEX_INFO message. For example: "foo,bar,baz" > - Client sends a similar list. For example: "baz,bar" > - The negotiated algorithm is (1) the first algorithm in the client's list > that (2) also appears in the server's list. > > In the above example, the negotiated algorithm is "baz". > > The "ext-info-s" and "ext-info-c" indicators are chosen so that two > correct implementations will never negotiate either, because only clients > send "ext-info-c", and only servers send "ext-info-s". If one of these > algorithms is negotiated, it means either one of the sides is seriously > buggy, or there's an attempt at some kind of attack. Therefore, > implementations should disconnect. > > A party that doesn't support EXT_INFO will never see "ext-info-c" or > "ext-info-s" being negotiated because it did not send it in its algorithm > list. Therefore, it cannot be negotiated. > Bingo - that answers my question. I was just making sure that a properly implemented SSH would disconnect because this happens as a result of a protocol violation, so it works with this way for SSLs that don't support this specification. I'll leave determining the proper level of paranoia beyond that to the professionals :-) > This is unless the party that doesn't support EXT_INFO is sending randomly > generated algorithm names and happens to hit upon that one. I trust no > honest implementation does this, except for fuzzing. If something like > fuzzing results in "ext-info-s" or "ext-info-c" being accidentally > negotiated, the aware implementation - of course - is the one that > disconnects. > > > > If this extension takes effect, the client MUST send the following > > message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: > > > > byte SSH_MSG_NEWCOMPRESS (value 8) > > > > I THINK the point is that the client's SSH_MSG_NEWCOMPRESS > > is sent after SSH_MSG_USERAUTH_SUCCESS, before the client > > sends its first SSH message that's compressed using the newly > > negotiated compression algorithm > > The implication here is that the client might have existing messages in > flight to the server when the server sends SSH_MSG_USERAUTH_SUCCESS. This > is not often the case, but it is possible: for example, user authentication > takes some time, and the client sends a keep-alive message. > > Because of this potential race condition, the server must wait until it > receives SSH_MSG_USERAUTH_SUCCESS before it assumes that compression in the > client-to-server direction is in effect. > > The language says "shortly" because it's hard to say what delay is > permissible here. Consider an intentionally pessimized case: > > - Suppose the server took extremely long to process the authentication > attempt. It's not unheard of that login processing can take 5 minutes. > - Suppose the client is set up to send frequent keep-alive messages to > prevent routers from disconnecting the TCP session, but it does not require > the server to respond to them. > - Suppose the server blocks and does nothing while it's processing the > login attempt. > > In these circumstances, the server may send SSH_MSG_USERAUTH_SUCCESS, only > to find in its TCP input buffer a large number of keep-alive messages from > the client which were sent while the server was processing. The server > needs to be able to handle all of these messages without compression, > before it can expect to receive the client's SSH_MSG_NEWCOMPRESS. > > My intent here was to encourage clients to send SSH_MSG_NEWCOMPRESS as > soon as they are able, while at the same time encouraging servers to > tolerate any reasonable number of packets from the client before this > message is received - where "reasonable" may be, to some extent, > implementation-defined. > > Based on this feedback, I'm leaning toward changing this language as > follows: > > "If this extension takes effect, the client MUST send the following message > within a reasonable number of outgoing messages after receiving > SSH_MSG_USERAUTH_SUCCESS - but not necessarily as the first such outgoing > message:" > > Maybe that makes it more clear. The existing, immediately following > paragraph attempts to explain the context without trying to dwell on it too > long: > > The purpose of NEWCOMPRESS is to avoid a race condition where the > server cannot reliably know whether a message sent by the client was > sent before or after receiving the server's USERAUTH_SUCCESS. > Your proposed new text, together with the following paragraph, is clear enough for me. Thanks for that. > > I would find this easier to understand, if the paragraph defining the > > terms was the first paragraph in the section, and then the description > > of the extension (which uses the term "elevation") followed. > > No problem. Will move. > > > > but I could imagine that adding elevation is the first step toward fewer > > SSH server implementations that always run with administrative rights > > just in case they ever need to use them, so the attack surface is > > getting smaller? > > Yes, that is the case. If clients can't be expected to implement the > "elevation" extension, Windows servers must elevate administrative users by > default. > > In a parable - without "elevation", all sessions from administrative users > have to run as "root" (on Windows), because there's no way to "sudo". > > > > ... And now I see that Mirja also asked about elevation, and your > answer to > > her was pretty much what I had guessed. Maybe it's worth summarizing > > your answer in section 3.4. > > I will do so. :-) > This all seems perfect to me, Thanks. Spencer --089e0828ff1c5b6100055915a188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Denis,

On Wed, Sep 13, 2017 at 1:11 AM, denis bider &l= t;denisbider= .ietf@gmail.com> wrote:
Hello,

replies below:


>=C2=A0In this text,
>
> =C2=A0Implement= ations MUST NOT send an incorrect indicator name for their
> =C2=A0role. Imp= lementations MAY disconnect if the counter-party sends an
> =C2=A0incorrect= indicator. If "ext-info-c" or "ext-info-s" ends up bei= ng
&g= t; =C2=A0negotiated as a key exchange method, the parties MUST disconnect.<= /span>
>
> why would a party that doen't suppor= t this extention disconnect?

This language= clarifies a corner case that's not expected to happen. Algorithm negot= iation in SSH works like this:

For each algorithm = type (e.g. key exchange) and direction (for some algorithm types, e.g. encr= yption):

- Server sends a comma-separated namelist= of algorithm names in the initial KEX_INFO message. For example: "foo= ,bar,baz"
- Client sends a similar list. For example: "= baz,bar"
- The negotiated algorithm is (1) the first algorit= hm in the client's list that (2) also appears in the server's list.=

In the above example, the negotiated algorithm is= "baz".

The "ext-info-s" and &= quot;ext-info-c" indicators are chosen so that two correct implementat= ions will never negotiate either, because only clients send "ext-info-= c", and only servers send "ext-info-s". If one of these algo= rithms is negotiated, it means either one of the sides is seriously buggy, = or there's an attempt at some kind of attack. Therefore, implementation= s should disconnect.

A party that doesn't supp= ort EXT_INFO will never see "ext-info-c" or "ext-info-s"= ; being negotiated because it did not send it in its algorithm list. Theref= ore, it cannot be negotiated.

B= ingo - that answers my question.=C2=A0

I was just = making sure that a properly implemented SSH would disconnect because this h= appens as a result of a protocol violation, so it works with this way for S= SLs that don't support this specification.

I&#= 39;ll leave determining the proper level of paranoia beyond that to the pro= fessionals :-)
=C2=A0
This is unless the party that doesn't support EXT_INFO i= s sending randomly generated algorithm names and happens to hit upon that o= ne. I trust no honest implementation does this, except for fuzzing. If some= thing like fuzzing results in "ext-info-s" or "ext-info-c&qu= ot; being accidentally negotiated, the aware implementation - of course - i= s the one that disconnects.

<= br>
> =C2=A0=C2=A0If this ext= ension takes effect, the client MUST send the following
> =C2=A0 message shortly after receiving SSH_M= SG_USERAUTH_SUCCESS:
>
> =C2=A0 =C2=A0 =C2=A0byte=C2=A0 =C2=A0 =C2=A0 = =C2=A0SSH_MSG_NEWCOMPRESS (value 8)
>
>=C2=A0I THINK the poi= nt is that the client's SSH_MSG_NEWCOMPRESS
> is sent after=C2=A0SSH_MSG_USERAUTH_SUCCESS, before the client
> sends its first SSH message that&#= 39;s=C2=A0compressed using the newl= y
> negotiated = compression algorithm

The implication here is= that the client might have existing messages in flight to the server when = the server sends SSH_MSG_USERAUTH_SUCCESS. This is not often the case, but = it is possible: for example, user authentication takes some time, and the c= lient sends a keep-alive message.

Because of this = potential race condition, the server must wait until it receives SSH_MSG_US= ERAUTH_SUCCESS before it assumes that compression in the client-to-server d= irection is in effect.

The language says "sho= rtly" because it's hard to say what delay is permissible here. Con= sider an intentionally pessimized case:

- Suppose = the server took extremely long to process the authentication attempt. It= 9;s not unheard of that login processing can take 5 minutes.
- Su= ppose the client is set up to send frequent keep-alive messages to prevent = routers from disconnecting the TCP session, but it does not require the ser= ver to respond to them.
- Suppose the server blocks and does noth= ing while it's processing the login attempt.

I= n these circumstances, the server may send SSH_MSG_USERAUTH_SUCCESS, only t= o find in its TCP input buffer a large number of keep-alive messages from t= he client which were sent while the server was processing. The server needs= to be able to handle all of these messages without compression, before it = can expect to receive the client's SSH_MSG_NEWCOMPRESS.

<= /div>
My intent here was to encourage clients to send SSH_MSG_NEWCOMPRE= SS as soon as they are able, while at the same time encouraging servers to = tolerate any reasonable number of packets from the client before this messa= ge is received - where "reasonable" may be, to some extent, imple= mentation-defined.

Based on this feedback, I'm= leaning toward changing this language as follows:

"If=C2=A0this extension takes e= ffect, the client MUST send the following=C2=A0message within a reasonable number of outgoing messages after r= eceiving SSH_MSG_USERAUTH_SUCCESS - but not necessarily as the first such o= utgoing message:"

Maybe that makes= it more clear. The existing, immediately following paragraph attempts to e= xplain the context without trying to dwell on it too long:

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

Your propose= d new text, together with the following paragraph, is clear enough for me. = Thanks for that.
=C2=A0
>=C2= =A0I would find this easier to unde= rstand, if the paragraph defining the
> terms was=C2=A0the first paragraph in the section, and then the = description
> of the e= xtension=C2=A0(which uses the term = "elevation") followed.

No pr= oblem. Will move.


>=C2=A0but I could imagine that adding elevation is the firs= t step toward fewer
&= gt; SSH=C2=A0server implementations= that always run with administrative rights
> just in case=C2=A0they ever need to use them, so the attack surface is
> getting smaller?
<= span style=3D"font-size:12.8px">
Yes, that is the case.=C2=A0If clients can't be expected to implement the "elevati= on" extension, Windows servers must elevate administrative users by de= fault.

<= div>In a parable - without "elevation= ", all sessions from administrative users have to run as "root&qu= ot; (on Windows), because there's no way to "sudo".

=

>=C2=A0... And= now I see that Mirja also asked about elevation, and your answer to=
> her=C2=A0was pretty much what I had guessed.=C2=A0 Maybe it&#= 39;s worth summarizing
&g= t; your answer=C2=A0in section 3.4.=

I will do so. :-)

This all seems perfect to me, Thanks.
=
Spencer=C2=A0
--089e0828ff1c5b6100055915a188-- From nobody Wed Sep 13 11:08:53 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C05031320D9; Wed, 13 Sep 2017 11:08:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 11:08:47 -0700 Archived-At: Subject: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) 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, 13 Sep 2017 18:08:48 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do agree with Spencer, the text that is non-normative reads as if this is fully deprecating any recommendation below 2048, but then the normative text just says SHOULD. Is there a reason this is not MUST? I know deprecating things takes a long time. From nobody Wed Sep 13 12:30:29 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 67A92126B6D; Wed, 13 Sep 2017 12:30:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 12:30:27 -0700 Archived-At: Subject: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) 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, 13 Sep 2017 19:30:27 -0000 Ben Campbell has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I plan to ballot "yes", but I want to discuss one point first. Alexey mentioned this in his comments, but I think it's discuss worthy. Hopefully it's an easy fix, and it may well be because I've missed something obvious. If people think it really, really needs to be this way, I will clear--but I want to discuss it first: - 2.5: The relative order in which extensions appear in an EXT_INFO message MUST be ignored by default; but an extension MAY specify that the order matters for that extension, in a specific way. I don't think allowing specific extensions to add ordering requirement works. It opens up the possibility of incompatible ordering requirements across extensions. As far as I can tell, the only control over this is the "IETF Consensus" requirement for adding new extensions. I'm open to arguments that this is good enough, but my knee-jerk response is that it puts an undue burden on the consensus process for little return. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay." That seems to be contradicted in section 2.4, which talks about two other potential times. -2.4, last paragraph (asterisk note): "The message MUST be sent at this point for the following reasons:" That's a confusing use of MUST. Do you mean that the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of fact, in which case the 2119 keyword is not appropriate? -2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it" That seems like a statement of fact rather than a grant of permission. If so, the 2119 MAY is not appropriate. Editorial: -2.1, first paragraph: "Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names:" That's hard to parse. Suggestion: "Applications implementing this mechanism MUST add one of the following indicator names to the "kex_algorithms" field for the first key exchange:" -2.5, 2nd to last paragraph: "... applications MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension’s extension-value." Redundant to similar normative statement in 2.3. From nobody Wed Sep 13 12:37:51 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 15A4C126B6D; Wed, 13 Sep 2017 12:37:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533146908.30532.5312387197836535820.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 12:37:49 -0700 Archived-At: Subject: [Curdle] Ben Campbell's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) 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, 13 Sep 2017 19:37:49 -0000 Ben Campbell has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the questions about "SHOULD" vs "MUST". - abstract: "insufficient against state-sponsored actors, and possibly an organization with enough computing resources" Should "an" be "any"? (Same question for section 2). From nobody Wed Sep 13 12:41:50 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 D4888126B6D; Wed, 13 Sep 2017 12:41:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533170386.30505.18041455973006366132.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 12:41:43 -0700 Archived-At: Subject: [Curdle] Ben Campbell's Yes on draft-ietf-curdle-des-des-des-die-die-die-04: (with COMMENT) 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, 13 Sep 2017 19:41:44 -0000 Ben Campbell has entered the following ballot position for draft-ietf-curdle-des-des-des-die-die-die-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Although there is precedent for obsoleting a spec and making it historical at the same time, I agree with Mirja that it doesn't seem to make sense in most cases. From nobody Wed Sep 13 12:42:08 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 792A3132192; Wed, 13 Sep 2017 12:42:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533172648.30510.3173942928121155891.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 12:42:06 -0700 Archived-At: Subject: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) 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, 13 Sep 2017 19:42:07 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir reviewer that it would be helpful to state that the extension negotiation between the client and server is performed after key exchange with confidentiality in the security considerations section. From nobody Wed Sep 13 14:55:29 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 23EF81200F3; Wed, 13 Sep 2017 14:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org, linda.dunbar@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533972713.30497.12654251869710189242.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 14:55:27 -0700 Archived-At: Subject: [Curdle] Benoit Claise's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) 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, 13 Sep 2017 21:55:27 -0000 Benoit Claise has entered the following ballot position for draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I understand that a new version will be published based on Linda Dunbar's OPS DIR review. Thank you. From nobody Wed Sep 13 14:59: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 E8B11132192; Wed, 13 Sep 2017 14:59:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org, shares@ndzh.com X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533995994.30425.14473077119451200331.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 14:59:19 -0700 Archived-At: Subject: [Curdle] Benoit Claise's No Objection on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) 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, 13 Sep 2017 21:59:20 -0000 Benoit Claise has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sue, in her OPS DIR review, brought up a good point. This document does not indicate whether it is wise for the operations system to log a report if it receives a less than 2048 bits. Would this enhance security or provide DoS attack surface. If logging creates a DoS surface, it would be good to include this as operational advice. From nobody Wed Sep 13 15:42:26 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 7193F132A65; Wed, 13 Sep 2017 15:42:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150534254545.29051.14338755931682118188.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 15:42:25 -0700 Archived-At: Subject: [Curdle] Suresh Krishnan's No Objection on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) 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, 13 Sep 2017 22:42:25 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-curdle-ssh-dh-group-exchange-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- RFC4419 specifies an example in Appendix A that uses a 1024 bit safe prime. Shouldn't this Appendix be updated by the draft as well? From nobody Wed Sep 13 21:05: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 C3B0713309A; Wed, 13 Sep 2017 21:05:09 -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 ayVhcKaGs-_J; Wed, 13 Sep 2017 21:05:07 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CC81330A3; Wed, 13 Sep 2017 21:05:06 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id m199so5256371lfe.3; Wed, 13 Sep 2017 21:05:06 -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=WQutboaleQqkhP1iA651/DU1IC9VVZvC6qkvPVU1+UU=; b=iFHCtIxRye11GYNPpXjhEkhy6yLUIsfgue0qEX3KD9hVgPyG6bFArBsdlak0pIPhb4 mD0S4ZNR6RAAdilLP2LXC2gYbNEXgUfVytNaDFdbl+ssdYjH3sqjKpUoQcuaGmoZma8u eQ1pdtfp/shDY7o6FLj6lageQLLHB3OYXj3cmBbPD84zUa3dXQWM8NC8fr2vtAowK1jm //Cw93AgHdK4/HaewVfzHPibzcbHi8pw5S1Gk6BH9J7iE+sEfCiE81gvMbDjdaKqKDwS TkbWWBto921SNd++GbACVh1NuA8AQEuCV8K+Hhbn1F2M1GATxljJBukJsat/aSKB4Ndr kIZw== 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=WQutboaleQqkhP1iA651/DU1IC9VVZvC6qkvPVU1+UU=; b=M2m9pi0YXhVcqaLSwOPnP/BTmIa06DgUDAGHxSIIEGxxWjc1v4IJ9oA28NLCiPRpvI ctcs6jvhkLjgF4F0W/+Aox/IZMh7LlUDKdL9pEAj6J8DRFoZHdMceaciZL6R2v6vfikA gqZwLsq1usB4gOgZFCqLXy8KdTfSG8O1Ybhd2rp3ZJeFS9ARQtDVPmq7LKcKHeyDBu+0 J7Zv5EHH4YVGOTM9AcOuyK1S2aSFhWHtMWeuNG8uc7FGn3ZTeWi6F2UXENx624BI77XV YAXQAcjWy+EjpjbRytoXxss7SmeVTuKHhavUT8eMXJzSEj1QAmQtBFgvIbjHzya/dAfw xqbw== X-Gm-Message-State: AHPjjUh9An87NzFQZvbQZUt9YJhn0KsT3nDpbyFS684mvqucO3/jQDQ0 KQ7Nh68UvHsMWiV+D8NBATnB0zZuy9WYzSVRloA= X-Google-Smtp-Source: AOwi7QCAX1takvvTlxRi+Qjqe5c++t+IwixVg4LmGwAeZnMdFVwRh3RuAxOXsXY6Zi4UF6XhHFYNhNmL4WwG5iD/7FE= X-Received: by 10.25.219.216 with SMTP id t85mr8130642lfi.88.1505361904670; Wed, 13 Sep 2017 21:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Wed, 13 Sep 2017 21:05:03 -0700 (PDT) In-Reply-To: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> From: denis bider Date: Wed, 13 Sep 2017 22:05:03 -0600 Message-ID: To: Ben Campbell Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="94eb2c184a32961ca605591e61f9" Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 04:05:10 -0000 --94eb2c184a32961ca605591e61f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I don't think allowing specific extensions > to add ordering requirement works. OK, fair point. That makes two votes against this. There is currently no known extension that needs this, and if one does arise, there exist other possible approaches for what is required. I have removed. > 2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, > without delay." That seems to be contradicted in section 2.4, which > talks about two other potential times. True. I have substantially rewritten sections 2.3. and 2.4. so as to not conflict, and to make this clearer. > 2.5, 2nd paragraph: "or it MAY be sufficient that only one party > includes it" That seems like a statement of fact rather than a grant > of permission. If so, the 2119 MAY is not appropriate. True. Changed to lowercase "can". > -2.1, first paragraph: "Applications implementing this mechanism > MUST add to the field "kex_algorithms", in their KEXINIT packet > sent for the first key exchange, one of the following indicator names:" > That's hard to parse. I'm guessing you're not a German speaker. :) The issue raised here seems to be that one needs to read to the end of the sentence to fully understand what is being added ("one of the following indicator names"). No problem, rearranged sentence. > -2.5, 2nd to last paragraph: "... applications MUST tolerate > any sequence of bytes; including null bytes at any position; > in an unknown extension=E2=80=99s extension-value." > Redundant to similar normative statement in 2.3. Aye, this is redundant on purpose. If this is not followed, it is devastating to compatibility. OpenSSH in particular has this issue in currently released versions (including 7.5, the latest). They stated they'll fix this for 7.6, but a workaround is required to NOT send extension-values containing null bytes to OpenSSH servers. The bug is not on purpose, it's because they have multiple functions to decode an SSH string - some that allow for binary data, some that don't. They accidentally used the one that doesn't allow binary data to decode extension-values. That's bad - and easy to proliferate as long as the most commonly used extensions don't exercise binary data. Fortunately, OpenSSH doesn't hide its version string, so the compatibility workaround is straightforward. That's not the case for all implementations. This is super important not to miss. The spec is somewhat big, and implementers might read one part at one time, and another part at another. I would prefer that this is not missed by anyone. denis On Wed, Sep 13, 2017 at 1:30 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I plan to ballot "yes", but I want to discuss one point first. Alexey > mentioned > this in his comments, but I think it's discuss worthy. Hopefully it's an > easy > fix, and it may well be because I've missed something obvious. If people > think > it really, really needs to be this way, I will clear--but I want to > discuss it > first: > > - 2.5: The relative order in which extensions appear in an > EXT_INFO message MUST be ignored by default; but an extension MAY > specify that the order matters for that extension, in a specific way. > > I don't think allowing specific extensions to add ordering requirement > works. > It opens up the possibility of incompatible ordering requirements across > extensions. As far as I can tell, the only control over this is the "IETF > Consensus" requirement for adding new extensions. I'm open to arguments > that > this is good enough, but my knee-jerk response is that it puts an undue > burden > on the consensus process for little return. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without > delay." > That seems to be contradicted in section 2.4, which talks about two other > potential times. > > -2.4, last paragraph (asterisk note): "The message MUST be sent at this > point > for the following reasons:" That's a confusing use of MUST. Do you mean > that > the message MUST NOT be sent unless the reasons are true? Or that if the > reasons are true, the message MUST be sent? Or is this just a statement o= f > fact, in which case the 2119 keyword is not appropriate? > > -2.5, 2nd paragraph: "or it MAY be sufficient that only one party include= s > it" > That seems like a statement of fact rather than a grant of permission. If > so, > the 2119 MAY is not appropriate. > > Editorial: > > -2.1, first paragraph: "Applications implementing this mechanism MUST add > to > the field > "kex_algorithms", in their KEXINIT packet sent for the first key > exchange, one of the following indicator names:" > > That's hard to parse. Suggestion: > "Applications implementing this mechanism MUST add one of the > following indicator names to the "kex_algorithms" field for the first > key exchange:" > > -2.5, 2nd to last paragraph: "... applications MUST > tolerate any sequence of bytes; including null bytes at any position; > in an unknown extension=E2=80=99s extension-value." > > Redundant to similar normative statement in 2.3. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c184a32961ca605591e61f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I don't thi= nk allowing specific extensions
> to add ordering requirement works.<= /span>

OK, fair point.

That = makes two votes against this. There is currently no known extension that ne= eds this, and if one does arise, there exist other possible approaches for = what is required. I have removed.


=
>=C2=A02.3: "This message is sent immediately after SSH_MS= G_NEWKEYS,
> without d= elay."=C2=A0That seems to be c= ontradicted in section 2.4, which
> talks about two other=C2=A0potential times.
True. I have substanti= ally rewritten sections 2.3. and 2.4. so as to not conflict, and to make th= is clearer.


>=C2=A02.5= , 2nd paragraph: "or it MAY be sufficient that only one party
> includes it"=C2=A0That seems like a statement of fact rath= er than a grant
> of p= ermission. If so,=C2=A0the 2119 MAY= is not appropriate.

=
True. Changed to lowerca= se "can".

<= /span>

>=C2=A0-2.1, first paragraph: "Applications implementing this mechanism<= /span>
> MUST add to=C2=A0the field=C2=A0"kex_algorithms", in their KEXINIT packet=
> sent for the first key=C2= =A0exchange, one of the following i= ndicator names:"
> Tha= t's hard to parse.=C2=A0
I'm guessing you&#= 39;re not a German speaker. :) The issue raised here seems to be that one n= eeds to read to the end of the sentence to fully understand what is being a= dded ("one of the following indicator names").
<= span style=3D"font-size:12.8px">
No problem, rearranged sentence.


>=C2=A0<= span style=3D"font-size:12.8px">-2.5, 2nd to last paragraph: "... appl= ications MUST=C2=A0tolerate<= /div>
> any sequence of bytes; incl= uding null bytes at any position;
> in an unknown extension=E2=80=99s extension-value.">=C2=A0Redu= ndant to similar normative statement in 2.3.

Aye, t= his is redundant on purpose. If this is not followed, it is devastating to = compatibility. OpenSSH in particular has this issue in currently released v= ersions (including 7.5, the latest). They stated they'll fix this for 7= .6, but a workaround is required to NOT send extension-values containing nu= ll bytes to OpenSSH servers.

The bug is not o= n purpose, it's because they have multiple functions to decode an SSH s= tring - some that allow for binary data, some that don't. They accident= ally used the one that doesn't allow binary data to decode extension-va= lues.

That's bad - and easy to proliferat= e as long as the most commonly used extensions don't exercise binary da= ta. Fortunately, OpenSSH doesn't hide its version string, so the compat= ibility workaround is straightforward. That's not the case for all impl= ementations.

<= /div>
This is super important not to m= iss. The spec is somewhat big, and implementers might read one part at one = time, and another part at another. I would prefer that this is not missed b= y anyone.

denis



On Wed, Sep 13, 2017 at 1:30 PM, Ben Campbell = <ben@nostrum.com> wrote:
Ben Campbell has ente= red the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I plan to ballot "yes", but I want to discuss one point first. Al= exey mentioned
this in his comments, but I think it's discuss worthy. Hopefully it'= ;s an easy
fix, and it may well be because I've missed something obvious. If peopl= e think
it really, really needs to be this way, I will clear--but I want to discuss= it
first:

- 2.5: The relative order in which extensions appear in an
=C2=A0 EXT_INFO message MUST be ignored by default; but an extension MAY =C2=A0 specify that the order matters for that extension, in a specific way= .

I don't think allowing specific extensions to add ordering requirement = works.
It opens up the possibility of incompatible ordering requirements across extensions. As far as I can tell, the only control over this is the "I= ETF
Consensus" requirement for adding new extensions. I'm open to argu= ments that
this is good enough, but my knee-jerk response is that it puts an undue bur= den
on the consensus process for little return.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Substantive:

-2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without= delay."
That seems to be contradicted in section 2.4, which talks about two other potential times.

-2.4, last paragraph (asterisk note): "The message MUST be sent at thi= s point
for the following reasons:" That's a confusing use of MUST. Do you= mean that
the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of<= br> fact, in which case the 2119 keyword is not appropriate?

-2.5, 2nd paragraph: "or it MAY be sufficient that only one party incl= udes it"
That seems like a statement of fact rather than a grant of permission. If s= o,
the 2119 MAY is not appropriate.

Editorial:

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

That's hard to parse.=C2=A0 Suggestion:
"Applications implementing this mechanism MUST add one of the
=C2=A0following indicator names to the "kex_algorithms" field for= the first
=C2=A0key exchange:"

-2.5, 2nd to last paragraph: "... applications MUST
=C2=A0 tolerate any sequence of bytes; including null bytes at any position= ;
=C2=A0 in an unknown extension=E2=80=99s extension-value."

Redundant to similar normative statement in 2.3.


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

--94eb2c184a32961ca605591e61f9-- From nobody Wed Sep 13 21:22: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 8B23C1330AB; Wed, 13 Sep 2017 21:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB5xGv3MrULw; Wed, 13 Sep 2017 21:22:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 67B491320B5; Wed, 13 Sep 2017 21:22:27 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8E4MK6D046915 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 23:22:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1D247E57-EDC3-464D-9DE3-E6130AD33ED1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 23:22:21 -0500 In-Reply-To: Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org To: denis bider References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 04:22:30 -0000 --Apple-Mail=_1D247E57-EDC3-464D-9DE3-E6130AD33ED1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for the response. Comments inline. I deleted sections that do not = seem to need further discussion. I do not see a response to my comment on the =E2=80=9C*=E2=80=9D note in = section 2.4. Did that change as part of the rewrite of that section that = you mention below? Thanks! Ben. > On Sep 13, 2017, at 11:05 PM, denis bider = wrote: >=20 > > I don't think allowing specific extensions > > to add ordering requirement works. >=20 > OK, fair point. >=20 > That makes two votes against this. There is currently no known = extension that needs this, and if one does arise, there exist other = possible approaches for what is required. I have removed. Thanks! I will clear my discuss. [=E2=80=A6] >=20 >=20 > > -2.1, first paragraph: "Applications implementing this mechanism > > MUST add to the field "kex_algorithms", in their KEXINIT packet > > sent for the first key exchange, one of the following indicator = names:" > > That's hard to parse. >=20 > I'm guessing you're not a German speaker. :) Don=E2=80=99t get me started on center embedding in English :-) > The issue raised here seems to be that one needs to read to the end of = the sentence to fully understand what is being added ("one of the = following indicator names"). >=20 > No problem, rearranged sentence. >=20 >=20 > > -2.5, 2nd to last paragraph: "... applications MUST tolerate > > any sequence of bytes; including null bytes at any position; > > in an unknown extension=E2=80=99s extension-value." > > Redundant to similar normative statement in 2.3. >=20 > Aye, this is redundant on purpose. If this is not followed, it is = devastating to compatibility. OpenSSH in particular has this issue in = currently released versions (including 7.5, the latest). They stated = they'll fix this for 7.6, but a workaround is required to NOT send = extension-values containing null bytes to OpenSSH servers. >=20 > The bug is not on purpose, it's because they have multiple functions = to decode an SSH string - some that allow for binary data, some that = don't. They accidentally used the one that doesn't allow binary data to = decode extension-values. >=20 > That's bad - and easy to proliferate as long as the most commonly used = extensions don't exercise binary data. Fortunately, OpenSSH doesn't hide = its version string, so the compatibility workaround is straightforward. = That's not the case for all implementations. >=20 > This is super important not to miss. The spec is somewhat big, and = implementers might read one part at one time, and another part at = another. I would prefer that this is not missed by anyone. I have no objection to reinforcing a requirement. The issue is redundant = normative language, where it becomes ambiguous which piece of text is = authoritative. It=E2=80=99s not a real issue here because the statements = are consistent (which is why I marked that as =E2=80=9Ceditorial=E2=80=9D.= ), but it can become a maintenance issue in the future if the resulting = RFC is updated or obsoleted. So my suggestion, which you can freely ignore, is to change one of the = occurrences to use descriptive (that is, non 2119) language. >=20 > denis >=20 >=20 >=20 > On Wed, Sep 13, 2017 at 1:30 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-curdle-ssh-ext-info-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I plan to ballot "yes", but I want to discuss one point first. Alexey = mentioned > this in his comments, but I think it's discuss worthy. Hopefully it's = an easy > fix, and it may well be because I've missed something obvious. If = people think > it really, really needs to be this way, I will clear--but I want to = discuss it > first: >=20 > - 2.5: The relative order in which extensions appear in an > EXT_INFO message MUST be ignored by default; but an extension MAY > specify that the order matters for that extension, in a specific = way. >=20 > I don't think allowing specific extensions to add ordering requirement = works. > It opens up the possibility of incompatible ordering requirements = across > extensions. As far as I can tell, the only control over this is the = "IETF > Consensus" requirement for adding new extensions. I'm open to = arguments that > this is good enough, but my knee-jerk response is that it puts an = undue burden > on the consensus process for little return. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without = delay." > That seems to be contradicted in section 2.4, which talks about two = other > potential times. >=20 > -2.4, last paragraph (asterisk note): "The message MUST be sent at = this point > for the following reasons:" That's a confusing use of MUST. Do you = mean that > the message MUST NOT be sent unless the reasons are true? Or that if = the > reasons are true, the message MUST be sent? Or is this just a = statement of > fact, in which case the 2119 keyword is not appropriate? >=20 > -2.5, 2nd paragraph: "or it MAY be sufficient that only one party = includes it" > That seems like a statement of fact rather than a grant of permission. = If so, > the 2119 MAY is not appropriate. >=20 > Editorial: >=20 > -2.1, first paragraph: "Applications implementing this mechanism MUST = add to > the field > "kex_algorithms", in their KEXINIT packet sent for the first key > exchange, one of the following indicator names:" >=20 > That's hard to parse. Suggestion: > "Applications implementing this mechanism MUST add one of the > following indicator names to the "kex_algorithms" field for the first > key exchange:" >=20 > -2.5, 2nd to last paragraph: "... applications MUST > tolerate any sequence of bytes; including null bytes at any = position; > in an unknown extension=E2=80=99s extension-value." >=20 > Redundant to similar normative statement in 2.3. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --Apple-Mail=_1D247E57-EDC3-464D-9DE3-E6130AD33ED1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZugP9AAoJEIBWSmyV89QNA5QP/RfAI2Kx7XyNIxOJIBxdZ00L 0Jw3PQsHlLfT3vuggH4Akh4s9f4OxAN1p+0CJF603FAU3OFDb/5ygJHUB4qNRk38 INHE16QSNxHl6bJ43oBtzQqTORGL1Huq+J9vRpmng+NWpSemx4fQfd7bwo2cEANU u/59kiIjr5hFNWrZLdA8KerQ2vBCo9SDBTOs1YeNDHDNIJ08J0fCbJiAb2I353J3 HDG1zzkEf7t4v2zBGlERHxujyRRvrQ/UKB05gfI3RndBi+pQSdCaglNSuOIsg+0P 9ToRKt870P9S8RaW2mx2FfcIyQBDO9vSOX/qwFokM2tlIHOjQwEa0+DRlRBUI5rB cESoD1ejv7BeQ06nL+/qW6jFfgd5kaeHKTGO85DJHtD5hg2fG+5Cpu0YYdjP+Vwk Skc1GEAhcBm2gCGb6vwGXky9Dm5bGd9HNThId4OjrXfXk6CJTPjcwfV8BpZFjyym +mr2vbnTxRji/QvE3XSIh5cD4A5PxUv+4BcEhe2sBnPd9LWjJUmonQ40Yrw9qIj2 tEpVUkcXf5Qh28ptWmYX76duQo6gRptV5hpgrwDng4FqycAIaTher4DEBI/MErMn suHWY7TeUSCHZpQCLD3rRCi5Q5ryCC8vsWfuXT0Q4hsKbubjJJipgVL9MSHd22kH aA8VgpPQ83zcuTKlZxEV =K83J -----END PGP SIGNATURE----- --Apple-Mail=_1D247E57-EDC3-464D-9DE3-E6130AD33ED1-- From nobody Wed Sep 13 21:24: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 9A3DB1320B5; Wed, 13 Sep 2017 21:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150536308262.12620.12702512428289572415.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 21:24:42 -0700 Archived-At: Subject: [Curdle] Ben Campbell's Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT) 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, 14 Sep 2017 04:24:43 -0000 Ben Campbell has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point. I've cleared, with the assumption the discussed change will make it into the final document. (I leave the non-blocking comments below for reference, although most of them have been addressed in the email discussion.) Substantive: -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay." That seems to be contradicted in section 2.4, which talks about two other potential times. -2.4, last paragraph (asterisk note): "The message MUST be sent at this point for the following reasons:" That's a confusing use of MUST. Do you mean that the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of fact, in which case the 2119 keyword is not appropriate? -2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it" That seems like a statement of fact rather than a grant of permission. If so, the 2119 MAY is not appropriate. Editorial: -2.1, first paragraph: "Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names:" That's hard to parse. Suggestion: "Applications implementing this mechanism MUST add one of the following indicator names to the "kex_algorithms" field for the first key exchange:" -2.5, 2nd to last paragraph: "... applications MUST tolerate any sequence of bytes; including null bytes at any position; in an unknown extension’s extension-value." Redundant to similar normative statement in 2.3. From nobody Wed Sep 13 21:47: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 5F29112895E; Wed, 13 Sep 2017 21:47:14 -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 dv9V_0G5AuHa; Wed, 13 Sep 2017 21:47:11 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C25A12422F; Wed, 13 Sep 2017 21:47:11 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id l196so5406291lfl.1; Wed, 13 Sep 2017 21:47:11 -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=XkL75XMMIh1LdemtSHIdSrnsH4pV614FqK9x025K5ro=; b=hwlRUTMzYcwcKoJsuNbb2R61cRfupUY17DoZqmP2qq1IzZJeWLhGJ7aF/t97R8pi+Q Ah9vHlz/OtaiBZWrpf9A7JqiW8pKEGPq/9p0rs8xMWHLFj0Py8NgqiL+MJgGWQtWXrff S9jyLoSjxwDFm1w3PE4Pgm3OCxMe4Hl6GYNNU8Uk9FMNtrIlmqWhlm6rLbzNRDhkrAn+ i3OLuaYMX991YQ3KtCu5CIw3zJ+Bv/UrNMi9J9VmnmMLFf/vEYlPqbgVJW9ttOmv4Mv1 1mwAR88G4pR3x8aZ3wtRwvZJKJuYPM4xPFGwLJ/m6FbgjavONChPwUtCFLVcrbaIpZdl i+yQ== 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=XkL75XMMIh1LdemtSHIdSrnsH4pV614FqK9x025K5ro=; b=drX/nPk62kZu23PQf6NRiZewL9BPHHQ8W3ktx8x5RW4xPpnh8gOTvmocosrBuNv5mZ sX2T5Kqjzl6BBSeWE7kBQHZUYWRnlycTiw9wH2iS10GLRN477/bzHLz9fF++iYQCS4Vy ncxlXAuPNe2PkRoWndWSK6GyY0SCmUtMu7IwgtU8mEXfL97sTD/iahm/vqLHUfBNftq7 0dHvoz6MKTknvqC1a5PP7zKaZj3N5wMdDEx8SNM3td8RGtjMUHfKcTXUXGPAtEpg+uQ/ WuaUyyFr0hcUU3ZuxeFFfd1QMSvUiF9gfWfx7r6THS5JiDSLeBSyQiyY0Wr3lXrc5AkU nJcA== X-Gm-Message-State: AHPjjUgVl+3pG9LTbgxxlEZjUWrWcvDKW4731t6kYBGePHXnuPY8FXgj CCwO+aHNT1VEuocE5UeZVVw6E+eBMJti7WA2g/M+Rw== X-Google-Smtp-Source: AOwi7QC9OD90wPdyWLEFWQ8mYcI8RcZnZv2qAxTtGB9xNzU2hfqikpZT9FrWHDN3dDnC1GkRSt1GjNMhyGia8Rvv5wg= X-Received: by 10.46.88.20 with SMTP id m20mr1822071ljb.72.1505364429469; Wed, 13 Sep 2017 21:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Wed, 13 Sep 2017 21:47:08 -0700 (PDT) In-Reply-To: <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> From: denis bider Date: Wed, 13 Sep 2017 22:47:08 -0600 Message-ID: To: Ben Campbell Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="f4030438d534137d0605591ef889" Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 04:47:14 -0000 --f4030438d534137d0605591ef889 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I do not see a response to my comment on the =E2=80=9C*=E2=80=9D note in = section 2.4. > Did that change as part of the rewrite of that section that you mention below? Aye, sorry for not mentioning that. Most of the text was kept, but it was slightly rearranged. The sentence containing the inappropriate MUST was replaced with: "The timing of the second opportunity is chosen for the following reasons." > Don=E2=80=99t get me started on center embedding in English :-) :D > The issue is redundant normative language, where it becomes > ambiguous which piece of text is authoritative. Aye - it does violate the one-definition rule. I have changed the first mention as follows: "Implementers' attention is called to Section 2.5., in particular the requirement to tolerate any sequence of bytes - including null bytes at any position - in an unknown extension's extension-value." I have previously contemplated whether to add explicit mention of the OpenSSH behavior up to 7.5. On the one hand, it is poor practice to reference individual implementations. But on the other hand, this is a widespread implementation that everyone will want to interoperate with. If we provide no guidance about how to handle this bug, it will throw implementers for a spin, and worse, the compatibility workarounds may not be ideal. (E.g. people may avoid sending binary extension-values to ANY version of OpenSSH, instead of just versions up to 7.5.) For this reason, I have provisionally added the following section under the "delay-compression" extension: 3.2.3. Compatibility Note: OpenSSH up to 7.5 This extension uses a binary extension-value encoding. OpenSSH clients up to and including version 7.5 advertise support to receive SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value containing null bytes. This is an error fixed in OpenSSH version 7.6. Implementations that wish to interoperate with OpenSSH 7.5 and earlier are advised to check the remote party's SSH version string, and omit this extension if an affected version is detected. Affected versions do not implement this extension, so there is no harm in omitting it. The extension SHOULD NOT be omitted if the detected OpenSSH version is 7.6 or higher. This would make it harder for the OpenSSH project to implement this extension in a higher version, if they so choose. This might be unusual, but since the bug exists in current versions, it will stay relevant for 5+ years. I think it may be worthwhile to ensure everyone's workarounds are consistent. The alternative would be to change the spec to disallow binary extension-values, but I think this is long-term inferior (especially since OpenSSH has committed to fixing the bug). denis On Wed, Sep 13, 2017 at 10:22 PM, Ben Campbell wrote: > Hi, > > Thanks for the response. Comments inline. I deleted sections that do not > seem to need further discussion. > > I do not see a response to my comment on the =E2=80=9C*=E2=80=9D note in = section 2.4. Did > that change as part of the rewrite of that section that you mention below= ? > > Thanks! > > Ben. > > > > On Sep 13, 2017, at 11:05 PM, denis bider > wrote: > > > > > I don't think allowing specific extensions > > > to add ordering requirement works. > > > > OK, fair point. > > > > That makes two votes against this. There is currently no known extensio= n > that needs this, and if one does arise, there exist other possible > approaches for what is required. I have removed. > > Thanks! I will clear my discuss. > > [=E2=80=A6] > > > > > > > > -2.1, first paragraph: "Applications implementing this mechanism > > > MUST add to the field "kex_algorithms", in their KEXINIT packet > > > sent for the first key exchange, one of the following indicator names= :" > > > That's hard to parse. > > > > I'm guessing you're not a German speaker. :) > > Don=E2=80=99t get me started on center embedding in English :-) > > > The issue raised here seems to be that one needs to read to the end of > the sentence to fully understand what is being added ("one of the followi= ng > indicator names"). > > > > No problem, rearranged sentence. > > > > > > > -2.5, 2nd to last paragraph: "... applications MUST tolerate > > > any sequence of bytes; including null bytes at any position; > > > in an unknown extension=E2=80=99s extension-value." > > > Redundant to similar normative statement in 2.3. > > > > Aye, this is redundant on purpose. If this is not followed, it is > devastating to compatibility. OpenSSH in particular has this issue in > currently released versions (including 7.5, the latest). They stated > they'll fix this for 7.6, but a workaround is required to NOT send > extension-values containing null bytes to OpenSSH servers. > > > > The bug is not on purpose, it's because they have multiple functions to > decode an SSH string - some that allow for binary data, some that don't. > They accidentally used the one that doesn't allow binary data to decode > extension-values. > > > > That's bad - and easy to proliferate as long as the most commonly used > extensions don't exercise binary data. Fortunately, OpenSSH doesn't hide > its version string, so the compatibility workaround is straightforward. > That's not the case for all implementations. > > > > This is super important not to miss. The spec is somewhat big, and > implementers might read one part at one time, and another part at another= . > I would prefer that this is not missed by anyone. > > I have no objection to reinforcing a requirement. The issue is redundant > normative language, where it becomes ambiguous which piece of text is > authoritative. It=E2=80=99s not a real issue here because the statements = are > consistent (which is why I marked that as =E2=80=9Ceditorial=E2=80=9D. ),= but it can become > a maintenance issue in the future if the resulting RFC is updated or > obsoleted. > > So my suggestion, which you can freely ignore, is to change one of the > occurrences to use descriptive (that is, non 2119) language. > > > > > denis > > > > > > > > On Wed, Sep 13, 2017 at 1:30 PM, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > > draft-ietf-curdle-ssh-ext-info-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I plan to ballot "yes", but I want to discuss one point first. Alexey > mentioned > > this in his comments, but I think it's discuss worthy. Hopefully it's a= n > easy > > fix, and it may well be because I've missed something obvious. If peopl= e > think > > it really, really needs to be this way, I will clear--but I want to > discuss it > > first: > > > > - 2.5: The relative order in which extensions appear in an > > EXT_INFO message MUST be ignored by default; but an extension MAY > > specify that the order matters for that extension, in a specific way. > > > > I don't think allowing specific extensions to add ordering requirement > works. > > It opens up the possibility of incompatible ordering requirements acros= s > > extensions. As far as I can tell, the only control over this is the "IE= TF > > Consensus" requirement for adding new extensions. I'm open to arguments > that > > this is good enough, but my knee-jerk response is that it puts an undue > burden > > on the consensus process for little return. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Substantive: > > > > -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without > delay." > > That seems to be contradicted in section 2.4, which talks about two oth= er > > potential times. > > > > -2.4, last paragraph (asterisk note): "The message MUST be sent at this > point > > for the following reasons:" That's a confusing use of MUST. Do you mean > that > > the message MUST NOT be sent unless the reasons are true? Or that if th= e > > reasons are true, the message MUST be sent? Or is this just a statement > of > > fact, in which case the 2119 keyword is not appropriate? > > > > -2.5, 2nd paragraph: "or it MAY be sufficient that only one party > includes it" > > That seems like a statement of fact rather than a grant of permission. > If so, > > the 2119 MAY is not appropriate. > > > > Editorial: > > > > -2.1, first paragraph: "Applications implementing this mechanism MUST > add to > > the field > > "kex_algorithms", in their KEXINIT packet sent for the first key > > exchange, one of the following indicator names:" > > > > That's hard to parse. Suggestion: > > "Applications implementing this mechanism MUST add one of the > > following indicator names to the "kex_algorithms" field for the first > > key exchange:" > > > > -2.5, 2nd to last paragraph: "... applications MUST > > tolerate any sequence of bytes; including null bytes at any position; > > in an unknown extension=E2=80=99s extension-value." > > > > Redundant to similar normative statement in 2.3. > > > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > > > --f4030438d534137d0605591ef889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I do not see a response to my comment on the =E2=80= =9C*=E2=80=9D note in section 2.4.
> Did that change as part of the = rewrite of that section that you mention below?

Ay= e, sorry for not mentioning that. Most of the text was kept, but it was sli= ghtly rearranged. The sentence containing the inappropriate MUST was replac= ed with:

"The timing of the second opportunit= y is chosen for the following reasons."


<= /div>
> Don=E2=80=99t get me started on center embedding in English = :-)

:D


>= ; The issue is redundant normative language, where it becomes
>= ; ambiguous which piece of text is authoritative.

= Aye - it does violate the one-definition rule.

I h= ave changed the first mention as follows:

&qu= ot;Implementers' attention is called to Section 2.5., in particular the= requirement to tolerate any sequence of bytes - including null bytes at an= y position - in an unknown extension's extension-value."


I have previously contemplated whether= to add explicit mention of the OpenSSH behavior up to 7.5. On the one hand= , it is poor practice to reference individual implementations. But on the o= ther hand, this is a widespread implementation that everyone will want to i= nteroperate with. If we provide no guidance about how to handle this bug, i= t will throw implementers for a spin, and worse, the compatibility workarou= nds may not be ideal. (E.g. people may avoid sending binary extension-value= s to ANY version of OpenSSH, instead of just versions up to 7.5.)

For this reason, I have provisionally added the following s= ection under the "delay-compression" extension:


3.2.3.=C2=A0 Compatibility Note: OpenSSH up to = 7.5

=C2=A0 This extension uses a binary extension-= value encoding. OpenSSH clients
=C2=A0 up to and including versio= n 7.5 advertise support to receive
=C2=A0 SSH_MSG_EXT_INFO, but d= isconnect on receipt of an extension-value
=C2=A0 containing null= bytes. This is an error fixed in OpenSSH version 7.6.

=
=C2=A0 Implementations that wish to interoperate with OpenSSH 7.5 and = earlier
=C2=A0 are advised to check the remote party's SSH ve= rsion string, and omit
=C2=A0 this extension if an affected versi= on is detected. Affected versions
=C2=A0 do not implement this ex= tension, so there is no harm in omitting it.
=C2=A0 The extension= SHOULD NOT be omitted if the detected OpenSSH version is
=C2=A0 = 7.6 or higher. This would make it harder for the OpenSSH project to
=C2=A0 implement this extension in a higher version, if they so choose.<= /div>


This might be unusual, but si= nce the bug exists in current versions, it will stay relevant for 5+ years.= I think it may be worthwhile to ensure everyone's workarounds are cons= istent.

The alternative would be to change the spe= c to disallow binary extension-values, but I think this is long-term inferi= or (especially since OpenSSH has committed to fixing the bug).
denis






On We= d, Sep 13, 2017 at 10:22 PM, Ben Campbell <ben@nostrum.com> wr= ote:
Hi,

Thanks for the response. Comments inline. I deleted sections that do not se= em to need further discussion.

I do not see a response to my comment on the =E2=80=9C*=E2=80=9D note in se= ction 2.4. Did that change as part of the rewrite of that section that you = mention below?

Thanks!

Ben.


> On Sep 13, 2017, at 11:05 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>
> > I don't think allowing specific extensions
> > to add ordering requirement works.
>
> OK, fair point.
>
> That makes two votes against this. There is currently no known extensi= on that needs this, and if one does arise, there exist other possible appro= aches for what is required. I have removed.

Thanks! I will clear my discuss.

[=E2=80=A6]

>
>
> > -2.1, first paragraph: "Applications implementing this mecha= nism
> > MUST add to the field "kex_algorithms", in their KEXINI= T packet
> > sent for the first key exchange, one of the following indicator n= ames:"
> > That's hard to parse.
>
> I'm guessing you're not a German speaker. :)

Don=E2=80=99t get me started on center embedding in English :-)

> The issue raised here seems to be that one needs to read to the end of= the sentence to fully understand what is being added ("one of the fol= lowing indicator names").
>
> No problem, rearranged sentence.
>
>
> > -2.5, 2nd to last paragraph: "... applications MUST tolerate=
> > any sequence of bytes; including null bytes at any position;
> > in an unknown extension=E2=80=99s extension-value."
> > Redundant to similar normative statement in 2.3.
>
> Aye, this is redundant on purpose. If this is not followed, it is deva= stating to compatibility. OpenSSH in particular has this issue in currently= released versions (including 7.5, the latest). They stated they'll fix= this for 7.6, but a workaround is required to NOT send extension-values co= ntaining null bytes to OpenSSH servers.
>
> The bug is not on purpose, it's because they have multiple functio= ns to decode an SSH string - some that allow for binary data, some that don= 't. They accidentally used the one that doesn't allow binary data t= o decode extension-values.
>
> That's bad - and easy to proliferate as long as the most commonly = used extensions don't exercise binary data. Fortunately, OpenSSH doesn&= #39;t hide its version string, so the compatibility workaround is straightf= orward. That's not the case for all implementations.
>
> This is super important not to miss. The spec is somewhat big, and imp= lementers might read one part at one time, and another part at another. I w= ould prefer that this is not missed by anyone.

I have no objection to reinforcing a requirement. The issue is redun= dant normative language, where it becomes ambiguous which piece of text is = authoritative. It=E2=80=99s not a real issue here because the statements ar= e consistent (which is why I marked that as =E2=80=9Ceditorial=E2=80=9D. ),= but it can become a maintenance issue in the future if the resulting RFC i= s updated or obsoleted.

So my suggestion, which you can freely ignore, is to change one of the occu= rrences to use descriptive (that is, non 2119)=C2=A0 language.

>
> denis
>
>
>
> On Wed, Sep 13, 2017 at 1:30 PM, Ben Campbell <ben@nostrum.com> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-curdle-ssh-ext-info-12: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> I plan to ballot "yes", but I want to discuss one point firs= t. Alexey mentioned
> this in his comments, but I think it's discuss worthy. Hopefully i= t's an easy
> fix, and it may well be because I've missed something obvious. If = people think
> it really, really needs to be this way, I will clear--but I want to di= scuss it
> first:
>
> - 2.5: The relative order in which extensions appear in an
>=C2=A0 =C2=A0EXT_INFO message MUST be ignored by default; but an extens= ion MAY
>=C2=A0 =C2=A0specify that the order matters for that extension, in a sp= ecific way.
>
> I don't think allowing specific extensions to add ordering require= ment works.
> It opens up the possibility of incompatible ordering requirements acro= ss
> extensions. As far as I can tell, the only control over this is the &q= uot;IETF
> Consensus" requirement for adding new extensions. I'm open to= arguments that
> this is good enough, but my knee-jerk response is that it puts an undu= e burden
> on the consensus process for little return.
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Substantive:
>
> -2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, wi= thout delay."
> That seems to be contradicted in section 2.4, which talks about two ot= her
> potential times.
>
> -2.4, last paragraph (asterisk note): "The message MUST be sent a= t this point
> for the following reasons:" That's a confusing use of MUST. D= o you mean that
> the message MUST NOT be sent unless the reasons are true? Or that if t= he
> reasons are true, the message MUST be sent? Or is this just a statemen= t of
> fact, in which case the 2119 keyword is not appropriate?
>
> -2.5, 2nd paragraph: "or it MAY be sufficient that only one party= includes it"
> That seems like a statement of fact rather than a grant of permission.= If so,
> the 2119 MAY is not appropriate.
>
> Editorial:
>
> -2.1, first paragraph: "Applications implementing this mechanism = MUST add to
> the field
>=C2=A0 =C2=A0"kex_algorithms", in their KEXINIT packet sent f= or the first key
>=C2=A0 =C2=A0exchange, one of the following indicator names:"
>
> That's hard to parse.=C2=A0 Suggestion:
> "Applications implementing this mechanism MUST add one of the
>=C2=A0 following indicator names to the "kex_algorithms" fiel= d for the first
>=C2=A0 key exchange:"
>
> -2.5, 2nd to last paragraph: "... applications MUST
>=C2=A0 =C2=A0tolerate any sequence of bytes; including null bytes at an= y position;
>=C2=A0 =C2=A0in an unknown extension=E2=80=99s extension-value." >
> Redundant to similar normative statement in 2.3.
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>


--f4030438d534137d0605591ef889-- From nobody Wed Sep 13 21:54: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 8DF2B1320BD; Wed, 13 Sep 2017 21:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNt6CgUcWbyG; Wed, 13 Sep 2017 21:54:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5A1EA12422F; Wed, 13 Sep 2017 21:54:01 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8E4rtLl051972 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 23:53:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_76AAFB5C-EFD9-4335-B339-9BC7315BC8B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 23:53:56 -0500 In-Reply-To: Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org To: denis bider References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 04:54:04 -0000 --Apple-Mail=_76AAFB5C-EFD9-4335-B339-9BC7315BC8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 13, 2017, at 11:47 PM, denis bider = wrote: >=20 > > I do not see a response to my comment on the =E2=80=9C*=E2=80=9D = note in section 2.4. > > Did that change as part of the rewrite of that section that you = mention below? >=20 > Aye, sorry for not mentioning that. Most of the text was kept, but it = was slightly rearranged. The sentence containing the inappropriate MUST = was replaced with: >=20 > "The timing of the second opportunity is chosen for the following = reasons.=E2=80=9D That works for me, thanks! [=E2=80=A6] > > The issue is redundant normative language, where it becomes > > ambiguous which piece of text is authoritative. >=20 > Aye - it does violate the one-definition rule. >=20 > I have changed the first mention as follows: >=20 > "Implementers' attention is called to Section 2.5., in particular the = requirement to tolerate any sequence of bytes - including null bytes at = any position - in an unknown extension's extension-value.=E2=80=9D >=20 Thanks! > I have previously contemplated whether to add explicit mention of the = OpenSSH behavior up to 7.5. On the one hand, it is poor practice to = reference individual implementations. But on the other hand, this is a = widespread implementation that everyone will want to interoperate with. = If we provide no guidance about how to handle this bug, it will throw = implementers for a spin, and worse, the compatibility workarounds may = not be ideal. (E.g. people may avoid sending binary extension-values to = ANY version of OpenSSH, instead of just versions up to 7.5.) >=20 > For this reason, I have provisionally added the following section = under the "delay-compression" extension: >=20 >=20 > 3.2.3. Compatibility Note: OpenSSH up to 7.5 >=20 > This extension uses a binary extension-value encoding. OpenSSH = clients > up to and including version 7.5 advertise support to receive > SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value > containing null bytes. This is an error fixed in OpenSSH version = 7.6. >=20 > Implementations that wish to interoperate with OpenSSH 7.5 and = earlier > are advised to check the remote party's SSH version string, and omit > this extension if an affected version is detected. Affected versions > do not implement this extension, so there is no harm in omitting it. > The extension SHOULD NOT be omitted if the detected OpenSSH version = is > 7.6 or higher. This would make it harder for the OpenSSH project to > implement this extension in a higher version, if they so choose. >=20 >=20 > This might be unusual, but since the bug exists in current versions, = it will stay relevant for 5+ years. I think it may be worthwhile to = ensure everyone's workarounds are consistent. >=20 > The alternative would be to change the spec to disallow binary = extension-values, but I think this is long-term inferior (especially = since OpenSSH has committed to fixing the bug). I don=E2=80=99t have a strong opinion here. One approach might be to say = an extension MUST NOT add binary values, but implementations MUST NOT = fail if one is present for an extension you don=E2=80=99t understand. In = any case, I will leave that to you and Ekr to decide. [=E2=80=A6] --Apple-Mail=_76AAFB5C-EFD9-4335-B339-9BC7315BC8B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZugtkAAoJEIBWSmyV89QNw7EQAMnydYrhQCINWx8ZdCjpYWm4 tEaDiZtgsrC7etYsNlVtwSofor6poc/Rr0zuO9C3flUWSbHouPCYx53a9/RcM9t1 0IHtQgZHtpRu/ao971LsjdeRiz0D15SKRAJRNMuDzIutlKGXiIPjDpm+CswfXj0R 3ekpnr1xBvaLg0I+0TofQp01WBCAiRDVmR55fLlpjsWv9XDfSWUmAVq1DfBS8duj RHd8nklkOTBmQC8ta7iG37BmBq4UtsPxQdWPxdqUqkrKSkEmcoJxH27rVlTJCGe9 J3iJp1WQw7IE0YpeXPhq8nvonLWcOrPx1QOYCv2V9OPGOXCAS8e8EZeBoFC9GVLm GPmP59kd88vG+0NHDhKW5nLWgGzzmlSE1Ypxza0gdjzqGNCyKmmGtXp/H4B5yNPR G1FmU7XO1P3sWJsuHPKa4ReOQlQLn3rZ9tRQGgVbYz7pCWNB2Mh+stVj1Db4h63I kcSk8G7eMjswDbBRnFjhmTNmKSz1SQIUMDE1ll3t1gUcXcA1EeXfwsimwo2+UrDn Fxi7ZejR65U/8ZR/qaclCJ6BDzmb7sLPN/UUxuXt8jk8j1moG8GIumeIqffeXiPV e/RR9tzLy2uwb6qC04tiTVpRq8q6NR+J7E5peYONoozwgTmGeFOO+aauipjYfSyA U7z8RC73k2UXm+Z6OQFX =xYpf -----END PGP SIGNATURE----- --Apple-Mail=_76AAFB5C-EFD9-4335-B339-9BC7315BC8B0-- From nobody Wed Sep 13 22:41: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 2F2CF126E64; Wed, 13 Sep 2017 22:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZUSuyQuBp_uY; Wed, 13 Sep 2017 22:41:23 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 4A9AB132C2A; Wed, 13 Sep 2017 22:41:23 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id m199so5582033lfe.3; Wed, 13 Sep 2017 22:41:23 -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=xZoBmTwX75U04572r1r4E1j++k7umcHnW3sdYw3lxjI=; b=ihynof/TfqLBMCpvzOeiPNPIPEe80Y+4nqQkI+mtfdkRzRy91hELR1BTP448ESGJpl UXIYdM0NATpJVhFmv0TO98Cy7/iMyShga7BnpJDhk5P3VvEsAt9TAEhfZOI89mEaseoV pByehvZevbEpThn7kyCYCuX05Hvhk6SVlSGUHc3M7n6+I9p5MXAhXFnsZDJyV9QKY+Gv EZZTexqntOs64+d5ynZJmb9s1a2jy3Ks4FZW6Rmk9W6UZ7ckNfjiDDg9hooQVqBwbtwa nehKBgACITDYnJHUc0z7lkcAGyqeJvELpYfQEsURMbIr5OStcDfzMMirkSGlL+BAJFnZ TpXA== 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=xZoBmTwX75U04572r1r4E1j++k7umcHnW3sdYw3lxjI=; b=uKM3h5OWU+XLWeV0ixSYlOQNRQ2ts2iIdNmBhSVTu+k27DZTgB1f1kH23oXvKGFd7i YS8vFymXZxJCRZVG4SExURlaKgsq130XjOiGTjoqlQMVFZSfqHWG4nbzdGe0XM9whAqW nVd9nKF01jr7D9d/Qg+A2C8Ssuqmm35guUeLzzybRlURKT1kGWVoC6POApONe1J9vGkK ylMAOYQhyT6+MZburjkbUi0MkX7hq7KpTyBXt72w8G/KUEPoo/6+xjKxcmDC5wDVP8Jq FmfA16lk4aGdxlq5MXkPEq8Vfd2YmiYBZLQwojDD05f5RLR1XCT1ykt8wpQPc2PkmoLN h8VA== X-Gm-Message-State: AHPjjUh3GFUe/xwcGNyNbUgspODBYgi/8rslQSaZekLrv7fKEcJ186Ns SY6UiHNWzTByN8Y7OCSXRsZL3LfJ+1j73QDAzB4= X-Google-Smtp-Source: AOwi7QAc7vLhsqZj+3Fcp+5zBq2a8i4KW4B/ATK2C/XDSMsQOhdgDQaLu6W49sFgbk4S+j+Or9BuAewpczXSwNvmeiM= X-Received: by 10.46.93.215 with SMTP id v84mr1019863lje.8.1505367681638; Wed, 13 Sep 2017 22:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Wed, 13 Sep 2017 22:41:20 -0700 (PDT) In-Reply-To: References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> From: denis bider Date: Wed, 13 Sep 2017 23:41:20 -0600 Message-ID: To: Ben Campbell Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a114a0ac0eba39205591fb900" Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 05:41:25 -0000 --001a114a0ac0eba39205591fb900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > One approach might be to say an extension MUST NOT add binary values, > but implementations MUST NOT fail if one is present for an extension you > don=E2=80=99t understand. Unfortunately, prohibiting extensions from having binary extension-values would have significant ramifications that would look very unsightly in the SSH protocol. For example, for something like the "delay-compression" extension that needs to encode two name-lists, if extension-value cannot be binary, then it would have to be Base64-encoded. This would be a very questionable choice in a protocol that is otherwise binary and has no reason to pessimize itself this way, other than that one particular implementation, at one point in time, used the wrong function to decode a string. :) On Wed, Sep 13, 2017 at 10:53 PM, Ben Campbell wrote: > > > On Sep 13, 2017, at 11:47 PM, denis bider > wrote: > > > > > I do not see a response to my comment on the =E2=80=9C*=E2=80=9D note= in section 2.4. > > > Did that change as part of the rewrite of that section that you > mention below? > > > > Aye, sorry for not mentioning that. Most of the text was kept, but it > was slightly rearranged. The sentence containing the inappropriate MUST w= as > replaced with: > > > > "The timing of the second opportunity is chosen for the following > reasons.=E2=80=9D > > That works for me, thanks! > > [=E2=80=A6] > > > > The issue is redundant normative language, where it becomes > > > ambiguous which piece of text is authoritative. > > > > Aye - it does violate the one-definition rule. > > > > I have changed the first mention as follows: > > > > "Implementers' attention is called to Section 2.5., in particular the > requirement to tolerate any sequence of bytes - including null bytes at a= ny > position - in an unknown extension's extension-value.=E2=80=9D > > > > Thanks! > > > > I have previously contemplated whether to add explicit mention of the > OpenSSH behavior up to 7.5. On the one hand, it is poor practice to > reference individual implementations. But on the other hand, this is a > widespread implementation that everyone will want to interoperate with. I= f > we provide no guidance about how to handle this bug, it will throw > implementers for a spin, and worse, the compatibility workarounds may not > be ideal. (E.g. people may avoid sending binary extension-values to ANY > version of OpenSSH, instead of just versions up to 7.5.) > > > > For this reason, I have provisionally added the following section under > the "delay-compression" extension: > > > > > > 3.2.3. Compatibility Note: OpenSSH up to 7.5 > > > > This extension uses a binary extension-value encoding. OpenSSH client= s > > up to and including version 7.5 advertise support to receive > > SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value > > containing null bytes. This is an error fixed in OpenSSH version 7.6. > > > > Implementations that wish to interoperate with OpenSSH 7.5 and earlie= r > > are advised to check the remote party's SSH version string, and omit > > this extension if an affected version is detected. Affected versions > > do not implement this extension, so there is no harm in omitting it. > > The extension SHOULD NOT be omitted if the detected OpenSSH version i= s > > 7.6 or higher. This would make it harder for the OpenSSH project to > > implement this extension in a higher version, if they so choose. > > > > > > This might be unusual, but since the bug exists in current versions, it > will stay relevant for 5+ years. I think it may be worthwhile to ensure > everyone's workarounds are consistent. > > > > The alternative would be to change the spec to disallow binary > extension-values, but I think this is long-term inferior (especially sinc= e > OpenSSH has committed to fixing the bug). > > I don=E2=80=99t have a strong opinion here. One approach might be to say = an > extension MUST NOT add binary values, but implementations MUST NOT fail i= f > one is present for an extension you don=E2=80=99t understand. In any case= , I will > leave that to you and Ekr to decide. > > [=E2=80=A6] > --001a114a0ac0eba39205591fb900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0One approach mi= ght be to say an extension MUST NOT add binary values,
> but implementations MUST NOT fail if one is pr= esent for an extension you
> don=E2=80=99t understand.

Unfortunately, pro= hibiting extensions from having binary extension-values would have signific= ant ramifications that would look very unsightly in the SSH protocol.

For example, for something like the "de= lay-compression" extension that needs to encode two name-lists, if ext= ension-value cannot be binary, then it would have to be Base64-encoded. Thi= s would be a very questionable choice in a protocol that is otherwise binar= y and has no reason to pessimize itself this way, other than that one parti= cular implementation, at one point in time, used the wrong function to deco= de a string. :)



On Wed, Sep 13, 2017 at 10:53 PM, Ben Campbell <ben@nostrum.com<= /a>> wrote:
> On Sep 13, 2017, at 11:47 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>
> > I do not see a response to my comment on the =E2=80=9C*=E2=80=9D = note in section 2.4.
> > Did that change as part of the rewrite of that section that you m= ention below?
>
> Aye, sorry for not mentioning that. Most of the text was kept, but it = was slightly rearranged. The sentence containing the inappropriate MUST was= replaced with:
>
> "The timing of the second opportunity is chosen for the fo= llowing reasons.=E2=80=9D

That works for me, thanks!

[=E2=80=A6]

> > The issue is redundant normative language, where it becomes
> > ambiguous which piece of text is authoritative.
>
> Aye - it does violate the one-definition rule.
>
> I have changed the first mention as follows:
>
> "Implementers' attention is called to Section 2.5., in= particular the requirement to tolerate any sequence of bytes - including n= ull bytes at any position - in an unknown extension's extension-value.= =E2=80=9D
>

Thanks!


> I have previously contemplated whether to add explicit mention of the = OpenSSH behavior up to 7.5. On the one hand, it is poor practice to referen= ce individual implementations. But on the other hand, this is a widespread = implementation that everyone will want to interoperate with. If we provide = no guidance about how to handle this bug, it will throw implementers for a = spin, and worse, the compatibility workarounds may not be ideal. (E.g. peop= le may avoid sending binary extension-values to ANY version of OpenSSH, ins= tead of just versions up to 7.5.)
>
> For this reason, I have provisionally added the following section unde= r the "delay-compression" extension:
>
>
> 3.2.3.=C2=A0 Compatibility Note: OpenSSH up to 7.5
>
>=C2=A0 =C2=A0This extension uses a binary extension-value encoding. Ope= nSSH clients
>=C2=A0 =C2=A0up to and including version 7.5 advertise support to recei= ve
>=C2=A0 =C2=A0SSH_MSG_EXT_INFO, but disconnect on receipt of an extensio= n-value
>=C2=A0 =C2=A0containing null bytes. This is an error fixed in OpenSSH v= ersion 7.6.
>
>=C2=A0 =C2=A0Implementations that wish to interoperate with OpenSSH 7.5= and earlier
>=C2=A0 =C2=A0are advised to check the remote party's SSH version st= ring, and omit
>=C2=A0 =C2=A0this extension if an affected version is detected. Affecte= d versions
>=C2=A0 =C2=A0do not implement this extension, so there is no harm in om= itting it.
>=C2=A0 =C2=A0The extension SHOULD NOT be omitted if the detected OpenSS= H version is
>=C2=A0 =C2=A07.6 or higher. This would make it harder for the OpenSSH p= roject to
>=C2=A0 =C2=A0implement this extension in a higher version, if they so c= hoose.
>
>
> This might be unusual, but since the bug exists in current versions, i= t will stay relevant for 5+ years. I think it may be worthwhile to ensure e= veryone's workarounds are consistent.
>
> The alternative would be to change the spec to disallow binary extensi= on-values, but I think this is long-term inferior (especially since OpenSSH= has committed to fixing the bug).

I don=E2=80=99t have a strong opinion here. One approach might be to= say an extension MUST NOT add binary values, but implementations MUST NOT = fail if one is present for an extension you don=E2=80=99t understand. In an= y case, I will leave that to you and Ekr to decide.

[=E2=80=A6]

--001a114a0ac0eba39205591fb900-- From nobody Wed Sep 13 22:45: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 BD7B3126E64; Wed, 13 Sep 2017 22:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POxkR0kiMiRg; Wed, 13 Sep 2017 22:45:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 78F29128D0F; Wed, 13 Sep 2017 22:45:22 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8E5jGrA060827 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 00:45:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B4EDB517-F65E-4356-B463-8EB95FF607ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 14 Sep 2017 00:45:16 -0500 In-Reply-To: Cc: The IESG , Daniel Migault , curdle-chairs , curdle , draft-ietf-curdle-ssh-ext-info@ietf.org To: denis bider References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 05:45:24 -0000 --Apple-Mail=_B4EDB517-F65E-4356-B463-8EB95FF607ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 14, 2017, at 12:41 AM, denis bider = wrote: >=20 > > One approach might be to say an extension MUST NOT add binary = values, > > but implementations MUST NOT fail if one is present for an extension = you > > don=E2=80=99t understand. >=20 > Unfortunately, prohibiting extensions from having binary = extension-values would have significant ramifications that would look = very unsightly in the SSH protocol. >=20 > For example, for something like the "delay-compression" extension that = needs to encode two name-lists, if extension-value cannot be binary, = then it would have to be Base64-encoded. This would be a very = questionable choice in a protocol that is otherwise binary and has no = reason to pessimize itself this way, other than that one particular = implementation, at one point in time, used the wrong function to decode = a string. :) That=E2=80=99s convincing. I will leave this up to the SSH experts to = figure out :-) Ben. --Apple-Mail=_B4EDB517-F65E-4356-B463-8EB95FF607ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZuhdsAAoJEIBWSmyV89QNxNUQAMJW37xtVHBnFC0CjxE3wBqA jDc8q1NSXarWOeNCcYsf+Mz0nwaOpRicMuDxCQ3pd7vgeZ/Sx/xZ3R+ixI6pic5I CCGuLWVbpTHHpdUpIuM7jaqOpZqL/EjlICymdiAjuNLcZJu0ABh49pegqv5Jifv9 xTy8GpXkInD5iqxVS+jF0V44inUvoz2OU8pLKxCPVxrqwTxpC64Hy74NVRx3HQsR UdxeM9b5hDgIJhC6yXB/XPhMiHqDR6yWkzXLAhxvf9dYYClmBCa3bpnOYt6iMQJZ OFM+0YGoYMYXy61l2GUc+aN//L3WkZvWn7X2KS5vwl0ePZ+h3P7ybrAI2k0kLsbF +HS5/5iCRB40gcWcKuusjy/0XKI9htMj96E1zYXG5ib6cdMazWd9PJ8hjfeT3UpQ W8CC9fwKDeldDjkfh0QwMTJ+kQiepVkrmxJMXUW5o7/mn2R/RZtp6BWf8mwhsr7d Z2yXqVqxw8cIGd/ocg+Xhi823hmcnpyRsVYBUub1zZBClrUgh7Yo4Yo8Lm5IWisb QwJyylVmhiff7j+D3kSuINxu3xb/MYKAqOdFLQJulNKaEfMW4cb4LMboglXa74Fx GNnbmkeo+HMB2yRxubuDcgA9EYWhv2MS70Acja2vZQZvxWmU/wNKW9hbl3JK+HTg JpfI2v/YfDef358ehfKn =e6cl -----END PGP SIGNATURE----- --Apple-Mail=_B4EDB517-F65E-4356-B463-8EB95FF607ED-- From nobody Thu Sep 14 05:17: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 4EDBC132397 for ; Thu, 14 Sep 2017 05:17:11 -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=unavailable 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 c7nF9QTD1e-y for ; Thu, 14 Sep 2017 05:17:10 -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 EBB1A133021 for ; Thu, 14 Sep 2017 05:17:03 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id w94so475052ioi.7 for ; Thu, 14 Sep 2017 05:17:03 -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=u/QkD4FpsCH+Z1kKOL5uPj2INmKwNhuLZzbmjQ9fBJ4=; b=BRLcqdSPyVDzRdW3NkO7Gb+2uv9qBy5lwZarM3+ZipSEijavcEgfY9Ux8olCgkS8o0 +sWgWF5UrwDYedncypMf9KlJdd/mfdyaUxIofV0j99nNHIIYvJ8maF4IyvOuPwHK2RjJ bzcH9+6WohxGgPFORSG6O/NdvTFCERH7M3ltU2z0rrrMLJezV8urhFuGBrWSTA9Fknhr HQKVlj+yRUKyo+5d/Jvg2rI7EROnO10dfKsCpIBArcIsZk6uWNge5t2jCS0atXLWSRvf XT4SigN2dU9S0KeI9q9rkwZk8dmm5D2jqO5P1SimtTdkoAF0CZvVggau6n316MtELzpF HLLw== 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=u/QkD4FpsCH+Z1kKOL5uPj2INmKwNhuLZzbmjQ9fBJ4=; b=F7j/QgUWgjNhRclZN9puM0tTKTSRFz3iSSoaz7d5hbjzNbP1w9nxrURHQs+lHM5pm1 VCGUOUc2dTUAe8l2ZFIYSXoD2TjjV/pD4W0bivPeMVoBkmXSj+EhfEBOwCbasglKQlnd SMoznkzxv0ekMDDxRH7NyWa8IixpgNP3LQWwGQu7DaJh+YYLlsictoRclMU1CMoWjzhJ G8bzhPGIkWrzWRDti92inOueLWc2ST8x7oTHI+e5WR9u+lGu+5xyLJluK1rEiG0kvB+v 7H57go47MxUTNi7lrInmbXDrAhI6yaAQSTWmuAhMbJ6ciofN3q1yvSQ4hUlWyfCAgKXs WAqw== X-Gm-Message-State: AHPjjUi0vCxPqHzkwpFmO+tfe5wrYqIMhlNQCbk2TbjbrlEO4aR5aAy0 Re6StrQr8IdeV/4uIJoDPMsT2CwbyxxtWOOqvy6ybw== X-Google-Smtp-Source: AOwi7QCPiaup8i2419f1ZjlgwxHkPGw8jIFy3HeiZTq3LrMk17iY00ef13HBIa0oTkNZYKNF7sFOc+IEXfCF2xWRpcA= X-Received: by 10.202.85.74 with SMTP id j71mr2736352oib.36.1505391423326; Thu, 14 Sep 2017 05:17:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Thu, 14 Sep 2017 05:16:22 -0700 (PDT) In-Reply-To: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 14 Sep 2017 05:16:22 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , curdle , Daniel Migault , draft-ietf-curdle-des-des-des-die-die-die@ietf.org, curdle Content-Type: multipart/alternative; boundary="001a113d37d20942560559254183" Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 12:17:11 -0000 --001a113d37d20942560559254183 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The situation here is that the algorithms are still in use, but we want people to stop using them. Based on Mirja's comments, it seems like neither of these is exactly on point. Personally, I'm happy with any, all, or none of these actions. Given this situation, what do others think? -Ekr On Mon, Sep 4, 2017 at 6:47 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-curdle-des-des-des-die-die-die-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des- > des-die-die-die/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is mainly a processing question, so probably more for the IESG to > discuss > than the authors: > > I understand the intention of obsoleting RFC4757 to declare that the > algorithms > described should not be used anymore, however, rfc4757 is an informationa= l > implementation description which is probably still deployed. Obsoleting a= n > informational implementation description seems a bit weird. Just would > like to > double-check with the rest of the IESG if that action appropriate...? > > Also obsoleting and moving to historic is not the same thing. The documen= t > says: > "This document recommends the reclassification of [RFC4757] as Historic." > One of the two actions (obsoleting or moving to historic) is enough. Whil= e > I > think moving to historic might actually be more appropriate than > obsoleting an > implementation description, it should only be moved to historic if this i= s > not > used and deployed anymore. Also moving to historic also requires a status > change action. > > > > > --001a113d37d20942560559254183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The situation here is that the algorithms are still in use= , but we want people to stop using them.

Based on Mirja&= #39;s comments, it seems like neither of these is exactly on point. Persona= lly, I'm happy with any, all, or none of these actions.

<= /div>
Given this situation, what do others think?

<= div>
-Ekr

On Mon, Sep 4, 2017 at 6:47 AM, Mirja K=C3=BCh= lewind <ietf@kuehlewind.net> wrote:
Mirja K=C3=BChlewind has entered the following ballot positio= n for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-curdle-des-des-des-die-die-die/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is mainly a processing question, so probably more for the IESG to disc= uss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algori= thms
described should not be used anymore, however, rfc4757 is an informational<= br> implementation description which is probably still deployed. Obsoleting an<= br> informational implementation description seems a bit weird. Just would like= to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document = says:
"This document recommends the reclassification of [RFC4757] as Histori= c."
One of the two actions (obsoleting or moving to historic) is enough. While = I
think moving to historic might actually be more appropriate than obsoleting= an
implementation description, it should only be moved to historic if this is = not
used and deployed anymore. Also moving to historic also requires a status change action.





--001a113d37d20942560559254183-- From nobody Thu Sep 14 05:19: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 EEE2F132397; Thu, 14 Sep 2017 05:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, 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 LFKOWTgNFTg4; Thu, 14 Sep 2017 05:19:52 -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 9C7BF120720; Thu, 14 Sep 2017 05:19:52 -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 v8ECHr1H025422; Thu, 14 Sep 2017 13:19:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HjAMQiHe/00CCBYY8bM9wLNqOZvqg3MW9+/d+/cUu+0=; b=TzTxmNTjE89YkHHjHF06ZZgR9RMHiG6uBd4WjkdC9Z3xdZ0JsUO2dd/JW2E9wYvcIulN pU8ZH6FTUyQsSu9m+6MG9it3nGleBSbaEdEjXVWY/440hTx3cjKIEbKNCYTaxKCuwihu nBSjhQKZ0AngIbjdfnUBOZgaccOxnkuaYABxepkzGrtUZbTwzPxMq3qId1kBODM9NUTw srhU32UlfV65omEp7zNElUDC4NWqn+THTzxhGpuPXMueuxfwlHc8MzoJNKTWnar9qiqG /TOhLus3o+90o5RkXJno/tBHYClB/wCDDd77cLHpKSaqiKr+LWUhyaK27/8cehGV01rZ 9w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2cx9syn569-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Sep 2017 13:19:48 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8ECFpS1028065; Thu, 14 Sep 2017 08:19:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cwwtxmqc1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Sep 2017 08:19:47 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 14 Sep 2017 07:19:46 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 14 Sep 2017 07:19:46 -0500 From: "Salz, Rich" To: Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , Daniel Migault , curdle , curdle , The IESG Thread-Topic: =?utf-8?B?W0N1cmRsZV0gIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0?= =?utf-8?B?LWlldGYtY3VyZGxlLWRlcy1kZXMtZGVzLWRpZS1kaWUtZGllLTA0OiAod2l0?= =?utf-8?Q?h_DISCUSS)?= Thread-Index: AQHTLVNoV405Zaqh+U+YG4RNA3zSjqK0XZsA Date: Thu, 14 Sep 2017 12:19:46 +0000 Message-ID: References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.136] Content-Type: multipart/alternative; boundary="_000_F91C80898E9348B2BA0B8B221C18A00Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-14_03:, , 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-1707230000 definitions=main-1709140182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709140182 Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 12:19:55 -0000 --_000_F91C80898E9348B2BA0B8B221C18A00Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXNu4oCZdCB0aGUgSUVTRyBmcmVlIHRvIHRha2UgdXAgdGhlIHJlY29tbWVuZGF0aW9uIGFuZCBz dGF0ZS1jaGFuZ2UgYXQgYW55IHRpbWU/DQoNCkkgdGhpbmsgdGhpcyBkb2N1bWVudCBjbGVhcmx5 IHNheXMgRE9O4oCZVCBETyBUSElTIGluIGJpZyBmbGFzaGluZyBsZXR0ZXJzIGFuZCB0aGF0IGFs bCBzaWduYWxzIGZvciB0aGlzIGFyZSBuZWVkZWQuDQoNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8 ZWtyQHJ0Zm0uY29tPg0KRGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciAxNCwgMjAxNyBhdCA4OjE2 IEFNDQpUbzogTWlyamEgS3VlaGx3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0Pg0KQ2M6ICJkcmFm dC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZUBpZXRmLm9yZyIgPGRyYWZ0LWll dGYtY3VyZGxlLWRlcy1kZXMtZGVzLWRpZS1kaWUtZGllQGlldGYub3JnPiwgRGFuaWVsIE1pZ2F1 bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4sICJjdXJkbGVAaWV0Zi5vcmciIDxjdXJk bGVAaWV0Zi5vcmc+LCAiY3VyZGxlLWNoYWlyc0BpZXRmLm9yZyIgPGN1cmRsZS1jaGFpcnNAaWV0 Zi5vcmc+LCAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0N1 cmRsZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jdXJkbGUtZGVz LWRlcy1kZXMtZGllLWRpZS1kaWUtMDQ6ICh3aXRoIERJU0NVU1MpDQoNClRoZSBzaXR1YXRpb24g aGVyZSBpcyB0aGF0IHRoZSBhbGdvcml0aG1zIGFyZSBzdGlsbCBpbiB1c2UsIGJ1dCB3ZSB3YW50 IHBlb3BsZSB0byBzdG9wIHVzaW5nIHRoZW0uDQoNCkJhc2VkIG9uIE1pcmphJ3MgY29tbWVudHMs IGl0IHNlZW1zIGxpa2UgbmVpdGhlciBvZiB0aGVzZSBpcyBleGFjdGx5IG9uIHBvaW50LiBQZXJz b25hbGx5LCBJJ20gaGFwcHkgd2l0aCBhbnksIGFsbCwgb3Igbm9uZSBvZiB0aGVzZSBhY3Rpb25z Lg0KDQpHaXZlbiB0aGlzIHNpdHVhdGlvbiwgd2hhdCBkbyBvdGhlcnMgdGhpbms/DQoNCi1Fa3IN Cg0KDQpPbiBNb24sIFNlcCA0LCAyMDE3IGF0IDY6NDcgQU0sIE1pcmphIEvDvGhsZXdpbmQgPGll dGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3cm90ZToNCk1p cmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQpkcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZS0wNDogRGlzY3Vz cw0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50 X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1sJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxa ZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1SOWRRZXZHOFBMVkZiRFRNOGhZa0Q2RjV2SUt3 U3QyTWxyUVdsalNEWFVnJnM9SHZvcTVGbFpyZ0hydk5LWFJtbzBYM1RzUWROMWxWQ3hnR3lTbmVw b21HSSZlPT4NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUvPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr ZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGN1cmRsZS0yRGRlcy0yRGRlcy0yRGRlcy0y RGRpZS0yRGRpZS0yRGRpZV8mZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExN MEdiUjBoOUZ2eDg2RnRzS0ktdyZtPVI5ZFFldkc4UExWRmJEVE04aFlrRDZGNXZJS3dTdDJNbHJR V2xqU0RYVWcmcz1mSHJvVVNXdGgtVW5EV01NdlBkaG5XYnZNeUc5Q1c5czVFS1RCRWZLN3lJJmU9 Pg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBp cyBtYWlubHkgYSBwcm9jZXNzaW5nIHF1ZXN0aW9uLCBzbyBwcm9iYWJseSBtb3JlIGZvciB0aGUg SUVTRyB0byBkaXNjdXNzDQp0aGFuIHRoZSBhdXRob3JzOg0KDQpJIHVuZGVyc3RhbmQgdGhlIGlu dGVudGlvbiBvZiBvYnNvbGV0aW5nIFJGQzQ3NTcgdG8gZGVjbGFyZSB0aGF0IHRoZSBhbGdvcml0 aG1zDQpkZXNjcmliZWQgc2hvdWxkIG5vdCBiZSB1c2VkIGFueW1vcmUsIGhvd2V2ZXIsIHJmYzQ3 NTcgaXMgYW4gaW5mb3JtYXRpb25hbA0KaW1wbGVtZW50YXRpb24gZGVzY3JpcHRpb24gd2hpY2gg aXMgcHJvYmFibHkgc3RpbGwgZGVwbG95ZWQuIE9ic29sZXRpbmcgYW4NCmluZm9ybWF0aW9uYWwg aW1wbGVtZW50YXRpb24gZGVzY3JpcHRpb24gc2VlbXMgYSBiaXQgd2VpcmQuIEp1c3Qgd291bGQg bGlrZSB0bw0KZG91YmxlLWNoZWNrIHdpdGggdGhlIHJlc3Qgb2YgdGhlIElFU0cgaWYgdGhhdCBh Y3Rpb24gYXBwcm9wcmlhdGUuLi4/DQoNCkFsc28gb2Jzb2xldGluZyBhbmQgbW92aW5nIHRvIGhp c3RvcmljIGlzIG5vdCB0aGUgc2FtZSB0aGluZy4gVGhlIGRvY3VtZW50IHNheXM6DQoiVGhpcyBk b2N1bWVudCByZWNvbW1lbmRzIHRoZSByZWNsYXNzaWZpY2F0aW9uIG9mIFtSRkM0NzU3XSBhcyBI aXN0b3JpYy4iDQpPbmUgb2YgdGhlIHR3byBhY3Rpb25zIChvYnNvbGV0aW5nIG9yIG1vdmluZyB0 byBoaXN0b3JpYykgaXMgZW5vdWdoLiBXaGlsZSBJDQp0aGluayBtb3ZpbmcgdG8gaGlzdG9yaWMg bWlnaHQgYWN0dWFsbHkgYmUgbW9yZSBhcHByb3ByaWF0ZSB0aGFuIG9ic29sZXRpbmcgYW4NCmlt cGxlbWVudGF0aW9uIGRlc2NyaXB0aW9uLCBpdCBzaG91bGQgb25seSBiZSBtb3ZlZCB0byBoaXN0 b3JpYyBpZiB0aGlzIGlzIG5vdA0KdXNlZCBhbmQgZGVwbG95ZWQgYW55bW9yZS4gQWxzbyBtb3Zp bmcgdG8gaGlzdG9yaWMgYWxzbyByZXF1aXJlcyBhIHN0YXR1cw0KY2hhbmdlIGFjdGlvbi4NCg0K DQoNCg0K --_000_F91C80898E9348B2BA0B8B221C18A00Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2597C485F4EE144287301E9860574CA9@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPklzbuKAmXQgdGhlIElFU0cgZnJlZSB0byB0YWtlIHVwIHRoZSByZWNvbW1lbmRh dGlvbiBhbmQgc3RhdGUtY2hhbmdlIGF0IGFueSB0aW1lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkkgdGhpbmsgdGhpcyBkb2N1bWVudCBjbGVhcmx5IHNheXMgRE9O4oCZVCBETyBUSElTIGlu IGJpZyBmbGFzaGluZyBsZXR0ZXJzIGFuZCB0aGF0IGFsbCBzaWduYWxzIGZvciB0aGlzIGFyZSBu ZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RXJp YyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2Rh eSwgU2VwdGVtYmVyIDE0LCAyMDE3IGF0IDg6MTYgQU08YnI+DQo8Yj5UbzogPC9iPk1pcmphIEt1 ZWhsd2luZCAmbHQ7aWV0ZkBrdWVobGV3aW5kLm5ldCZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O2RyYWZ0LWlldGYtY3VyZGxlLWRlcy1kZXMtZGVzLWRpZS1kaWUtZGllQGlldGYub3JnJnF1b3Q7 ICZsdDtkcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZUBpZXRmLm9yZyZn dDssIERhbmllbCBNaWdhdWx0ICZsdDtkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20mZ3Q7LCAm cXVvdDtjdXJkbGVAaWV0Zi5vcmcmcXVvdDsgJmx0O2N1cmRsZUBpZXRmLm9yZyZndDssICZxdW90 O2N1cmRsZS1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O2N1cmRsZS1jaGFpcnNAaWV0Zi5vcmcm Z3Q7LCAmcXVvdDtpZXNnQGlldGYub3JnJnF1b3Q7DQogJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQ3VyZGxlXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZS0wNDogKHdpdGgg RElTQ1VTUyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBzaXR1YXRpb24gaGVyZSBpcyB0aGF0IHRoZSBhbGdvcml0aG1zIGFy ZSBzdGlsbCBpbiB1c2UsIGJ1dCB3ZSB3YW50IHBlb3BsZSB0byBzdG9wIHVzaW5nIHRoZW0uDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIE1p cmphJ3MgY29tbWVudHMsIGl0IHNlZW1zIGxpa2UgbmVpdGhlciBvZiB0aGVzZSBpcyBleGFjdGx5 IG9uIHBvaW50LiBQZXJzb25hbGx5LCBJJ20gaGFwcHkgd2l0aCBhbnksIGFsbCwgb3Igbm9uZSBv ZiB0aGVzZSBhY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5HaXZlbiB0aGlzIHNpdHVhdGlvbiwgd2hhdCBkbyBvdGhlcnMgdGhpbms/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIFNlcCA0LCAyMDE3IGF0IDY6NDcgQU0sIE1pcmphIEvD vGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiB0YXJnZXQ9 Il9ibGFuayI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+TWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGll LWRpZS0wNDogRGlzY3Vzczxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1 c3MtMkRjcml0ZXJpYS5odG1sJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42 TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209UjlkUWV2RzhQTFZGYkRUTTho WWtENkY1dklLd1N0Mk1sclFXbGpTRFhVZyZhbXA7cz1Idm9xNUZsWnJnSHJ2TktYUm1vMFgzVHNR ZE4xbFZDeGdHeVNuZXBvbUdJJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0 Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGN1cmRsZS0yRGRlcy0yRGRlcy0yRGRlcy0yRGRpZS0y RGRpZS0yRGRpZV8mYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1w O3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1SOWRRZXZHOFBMVkZiRFRNOGhZa0Q2RjV2 SUt3U3QyTWxyUVdsalNEWFVnJmFtcDtzPWZIcm9VU1d0aC1VbkRXTU12UGRobldidk15RzlDVzlz NUVLVEJFZks3eUkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUvPC9h Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpESVNDVVNTOjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaGlzIGlzIG1haW5seSBhIHByb2Nlc3NpbmcgcXVl c3Rpb24sIHNvIHByb2JhYmx5IG1vcmUgZm9yIHRoZSBJRVNHIHRvIGRpc2N1c3M8YnI+DQp0aGFu IHRoZSBhdXRob3JzOjxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCB0aGUgaW50ZW50aW9uIG9mIG9i c29sZXRpbmcgUkZDNDc1NyB0byBkZWNsYXJlIHRoYXQgdGhlIGFsZ29yaXRobXM8YnI+DQpkZXNj cmliZWQgc2hvdWxkIG5vdCBiZSB1c2VkIGFueW1vcmUsIGhvd2V2ZXIsIHJmYzQ3NTcgaXMgYW4g aW5mb3JtYXRpb25hbDxicj4NCmltcGxlbWVudGF0aW9uIGRlc2NyaXB0aW9uIHdoaWNoIGlzIHBy b2JhYmx5IHN0aWxsIGRlcGxveWVkLiBPYnNvbGV0aW5nIGFuPGJyPg0KaW5mb3JtYXRpb25hbCBp bXBsZW1lbnRhdGlvbiBkZXNjcmlwdGlvbiBzZWVtcyBhIGJpdCB3ZWlyZC4gSnVzdCB3b3VsZCBs aWtlIHRvPGJyPg0KZG91YmxlLWNoZWNrIHdpdGggdGhlIHJlc3Qgb2YgdGhlIElFU0cgaWYgdGhh dCBhY3Rpb24gYXBwcm9wcmlhdGUuLi4/PGJyPg0KPGJyPg0KQWxzbyBvYnNvbGV0aW5nIGFuZCBt b3ZpbmcgdG8gaGlzdG9yaWMgaXMgbm90IHRoZSBzYW1lIHRoaW5nLiBUaGUgZG9jdW1lbnQgc2F5 czo8YnI+DQomcXVvdDtUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgdGhlIHJlY2xhc3NpZmljYXRp b24gb2YgW1JGQzQ3NTddIGFzIEhpc3RvcmljLiZxdW90Ozxicj4NCk9uZSBvZiB0aGUgdHdvIGFj dGlvbnMgKG9ic29sZXRpbmcgb3IgbW92aW5nIHRvIGhpc3RvcmljKSBpcyBlbm91Z2guIFdoaWxl IEk8YnI+DQp0aGluayBtb3ZpbmcgdG8gaGlzdG9yaWMgbWlnaHQgYWN0dWFsbHkgYmUgbW9yZSBh cHByb3ByaWF0ZSB0aGFuIG9ic29sZXRpbmcgYW48YnI+DQppbXBsZW1lbnRhdGlvbiBkZXNjcmlw dGlvbiwgaXQgc2hvdWxkIG9ubHkgYmUgbW92ZWQgdG8gaGlzdG9yaWMgaWYgdGhpcyBpcyBub3Q8 YnI+DQp1c2VkIGFuZCBkZXBsb3llZCBhbnltb3JlLiBBbHNvIG1vdmluZyB0byBoaXN0b3JpYyBh bHNvIHJlcXVpcmVzIGEgc3RhdHVzPGJyPg0KY2hhbmdlIGFjdGlvbi48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_F91C80898E9348B2BA0B8B221C18A00Fakamaicom_-- From nobody Thu Sep 14 05:23: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 89F47120720 for ; Thu, 14 Sep 2017 05:23:16 -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=unavailable 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 hAClyHnFtT_h for ; Thu, 14 Sep 2017 05:23:12 -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 A23BC133074 for ; Thu, 14 Sep 2017 05:23:12 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id h66so514914ioh.11 for ; Thu, 14 Sep 2017 05:23:12 -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=ZbdMIGsjtqwg1xRIcS1W0VOVrRqAIdSd7//wciLpeMQ=; b=LgIOkkse3CQd9CQXdAyLpZjY/GyJF9wSZP1lPr3KN+pmdS2qmHkvKd2/RQ8P7nuQiP +qP/enQTr/0n3DHvqdWMOx8HiI4Inl46j8JIttkCeupC8tftebtk1GPriWYxShJUyAti /LSABanJ4FefVscIAJ+i0SM4xp74lBPve2CT8K+o/Rhd3vDxplK1k0ValoCZQkj81SJQ 4ReES+ja7ps8ztKXcVmEQSG6VEAzhn0jGGzPPmfPGMcsQHy1pu8zMLqOwxxyn57ZSPna M4hR55xCXkuJ1h6IzetDGQyh4sAg8Kca3kgJQt5XUCDTU3EOJwJQnBqlfWGZMZRWjmk3 Ba3w== 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=ZbdMIGsjtqwg1xRIcS1W0VOVrRqAIdSd7//wciLpeMQ=; b=PzEoi8SzOKygdFekdQnUAKYTygvFgPwSn1MYVeilXJzk2wo98C3zJWPXpncPWmX939 +VKQOjuFVk91Yi0O2Xox6oSDFu0Ir6ci9waCi9xMCBpmB8ls4CG5OkVgQT4TzmJnLaBT u05dus1ZzfhaGXjbh/bRziAwkS5gpAIlp+qsyAMusOKh7QqYWigGrTF3Kfgj+fHJgnOh eBfoRRXHs/r7caOtLx4vOzcdPy2/MrXNZgeWf+DQ+cbQjFxbhvMVKUHiPrhXuu4oPMTZ N9cTVP4RGOYCMEINBEKCLs+b9+wef6NcO5J+TShHK6G5TTYWAZFbkoxa6t/OfGdr7N0g Dj3Q== X-Gm-Message-State: AHPjjUgPpnBZ7uXBNs6vohaKaN2VJGwjj4X5vOa/LuZsRWhq3bd1Hyv/ yTJ1QDr9e2BIlsqiLdszWG4wSXobw7a5orU+xSUh+A== X-Google-Smtp-Source: AOwi7QAwF9E35KphuRx8qvWJ5JcMK6mS3hvGf9bh4kyChKoT/cQt3NshIEqjtp7hyiccHtEn3wPb+a9mMSRt7h9GR3o= X-Received: by 10.202.221.7 with SMTP id u7mr2778396oig.166.1505391791973; Thu, 14 Sep 2017 05:23:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Thu, 14 Sep 2017 05:22:31 -0700 (PDT) In-Reply-To: References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> From: Eric Rescorla Date: Thu, 14 Sep 2017 05:22:31 -0700 Message-ID: To: denis bider Cc: Alexey Melnikov , Daniel Migault , curdle , curdle-chairs , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a113cf39c02420305592557b4" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 12:23:16 -0000 --001a113cf39c02420305592557b4 Content-Type: text/plain; charset="UTF-8" It sounds like we have resolutions to both Adam's and Alexey's issues. Denis, can you please submit a new draft and then (assuming it is satisfactory to them) Adam and Alexey can clear. -Ekr On Wed, Sep 13, 2017 at 6:48 AM, denis bider wrote: > > If you can list an example here for both the client side and the server > side, that would be great. > > There is no difference between what the two send. Added a line to explain > that as well. > > > > capability negotiation frameworks and very few of them (at the moment > > I can't think of any, actually) have dependencies on order > > Not sure if I understand you correctly, but SSH is completely dependent on > order in algorithm lists (client algorithm order matters), and I believe so > is TLS (server algorithm order matters). > > The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default, > because the extensions are assumed to be independent. However, I see no > reason to prevent it from becoming an algorithm list for some purposes, if > the goals of some extensions overlap. > > Note that it takes zero effort to allow for this use; and requires writing > unnecessary code to prevent. > > I'm not enthusiastic about writing unnecessary code to prevent a > particular type of use, just to prevent people doing something in the > future. The idea, honestly, seems stupid. > > > > My gut feeling is that you will never need this, so I wanted to know if > you actually > > can provide an example that depends on order. > > It would have to be two or more extensions with overlapping goals. For > example: > > 1. Extension A attempts to address situation X. > > 2. Extension A is flawed in situation Y, which bothers some people. > > 3. Extension B is developed to addresses situations X+Y. However, being > more complete, it is much more complex than Extension A. Past experience > shows that there will be existing servers which will only do Extension A > well. They might implement B, but it will be a hack job. > > 4. Therefore, Extension B specifies itself as a potential replacement for > Extension A, but allows servers to signal which one they prefer by > controlling the order in which the extensions appear. If both extensions > are advertised by both parties, then Extension B is used IF it is listed > first by the server. Otherwise, if Extension A is listed first, it is used. > > Common example - Extension A favored by Linux servers, Extension B favored > by everyone else. The story of SFTP. > > > > I think explaining this in the document would be useful. > > "Penalties" sounds a bit vague. > > Added footnote to explain. > > denis > > > > > On Wed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov > wrote: > >> On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote: >> >> > It is not clear for me from the formatting whether the first >> > name-list is sent by the client and the second by the server, >> > or both lists are always included in the value. I suspect it >> > is the former, but can you please clarify? >> >> SSH negotiates compression, integrity, and encryption algorithms >> separately for each direction. Both lists are sent by both parties. Not >> just here, but also in KEXINIT. >> >> This is used rarely in practice, but this draft keeps to the same >> practice, so as not to bundle a reduction of functionality (i.e. requiring >> same compression for both directions) in the same package as an extension >> (i.e. providing a mechanism for delayed activation of compression). >> >> The next draft will include an example of encoding, as suggested by Adam. >> This should make things clearer, even for readers unfamiliar with SSH. >> >> Yes, I think this will help. If you can list an example here for both the >> client side and the server side, that would be great. >> >> >> > 1) Sentences like: >> > Use of Receivers MUST tolerate any sequence of bytes; including >> > null bytes at any position; in an unknown extension's extension-value. >> >> Reads fine to me. Still, I changed these to use dashes. >> >> >> > Can you provide an example of why depending on order >> > would be useful? This potentially makes it harder to implement. >> >> It is the nature of an extension mechanism that it intends to be open to >> unforeseen circumstances. If we could come up with examples for all >> possible future uses, extensions would not be required. >> >> For this reason, I would prefer if you can demonstrate how allowing for >> this possibility makes anything harder to implement. In my implementation >> experience, it doesn't. >> >> I implemented multiple capability negotiation frameworks and very few of >> them (at the moment I can't think of any, actually) have dependencies on >> order. Dealing with one element at a time seems a bit simpler. >> >> My gut feeling is that you will never need this, so I wanted to know if >> you actually can provide an example that depends on order. >> >> > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. >> > It would be less confusing if you used the latter consistently >> everywhere. >> >> This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, >> NEWCOMPRESS, and USERAUTH_SUCCESS. >> >> OK, I changed this to use the SSH_MSG_ prefix always. >> >> Thank you. >> >> >> > This extension is sent by the server, and contains a list of public >> > key algorithms that the server is able to process as part of a >> > "publickey" authentication request. If a client sends this extension, >> > the server MAY ignore it, and MAY disconnect. >> > >> > Why would the client disconnect when seeing this extension? Does it >> mean it is >> > broken? >> > >> > Also, as the client can always disconnect at any point, why mentioning >> this >> > here? >> >> I believe you have misread the text in this case. It should be clear from >> the above quoted snippet. >> >> Oh, do you mean that this is never supposed to be sent by the client? In >> this case, yes, I misread it. Never mind. >> >> >> > Can you elaborate on what do you mean by "authentication penalties" >> > in this context? >> >> SSH servers commonly implement some way of locking out or throttling IP >> addresses that make frequent login attempts, so as to deter brute force >> password guessing, username guessing, and similar undesired behaviors. >> >> Some servers apply such penalties to clients that attempt to use an >> unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the >> client's IP address being locked out. >> >> The "server-sig-algs" extension provides a way for the client to know >> that the server supports e.g. "rsa-sha2-256" before it attempts to use it, >> to avoid a potential IP lockout. >> >> I think explaining this in the document would be useful. "Penalties" >> sounds a bit vague. >> >> On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov >> wrote: >> >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-curdle-ssh-ext-info-12: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is generally a good and useful document. I have some minor comments I >> would like to discuss: >> >> 3.2. "delay-compression" >> >> This extension MAY be sent by both parties as follows: >> >> string "delay-compression" >> string: >> name-list compression_algorithms_client_to_server >> name-list compression_algorithms_server_to_client >> >> It is not clear for me from the formatting whether the first name-list is >> sent >> by the client and the second by the server, or both lists are always >> included >> in the value. I suspect it is the former, but can you please clarify? >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1) Sentences like: >> Use of Receivers MUST tolerate any sequence of bytes; including null >> bytes >> at any position; in an unknown extension's extension-value. >> or >> In particular, applications MUST tolerate any sequence of bytes; >> including >> null bytes at any position; in an unknown extension's extension-value. >> >> Use of punctuation is not my strongest point, but I am reasonably certain >> that >> use of ";" is not correct here. I think you should use (). Otherwise these >> sentences are reading as a list of 3 things, yet in both cases the 3rd is >> a >> continuation of the 1st. >> >> 2) In Section 2.5: >> >> The relative order in which extensions appear in an >> EXT_INFO message MUST be ignored by default; but an extension MAY >> specify that the order matters for that extension, in a specific way. >> >> Can you provide an example of why depending on order would be useful? This >> potentially makes it harder to implement. >> >> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would >> be >> less confusing if you used the latter consistently everywhere. >> >> 3) In 3.1: >> >> This extension is sent by the server, and contains a list of public >> key algorithms that the server is able to process as part of a >> "publickey" authentication request. If a client sends this extension, >> the server MAY ignore it, and MAY disconnect. >> >> Why would the client disconnect when seeing this extension? Does it mean >> it is >> broken? >> >> Also, as the client can always disconnect at any point, why mentioning >> this >> here? >> >> If a server does not send this extension, a client MUST NOT make any >> assumptions about the server's public key algorithm support, and MAY >> proceed with authentication requests using trial and error. Note that >> implementations are known to exist that apply authentication penalties >> if the client attempts to use an unexpected public key algorithm. >> >> Can you elaborate on what do you mean by "authentication penalties" in >> this >> context? >> >> >> _______________________________________________ >> 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 > > --001a113cf39c02420305592557b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It sounds like we have resolutions to both Adam's and = Alexey's issues. Denis, can you please submit a new draft and then (ass= uming it is satisfactory to them) Adam and Alexey can clear.

=
-Ekr


On Wed, Sep 13, 2017 at 6:48 AM, denis bider <denisbider.ietf@gmail.com> wrote:
>=C2=A0If you can list an example here for both the client side and the = server side, that would be great.

There is n= o difference between what the two send. Added a line to explain that as wel= l.

<= /span>

>=C2=A0capability negotiation frameworks and very few of them (at the moment<= /span>
> I can't think of= any, actually) have dependencies on order

Not sure if I understand you correctly, but SSH is completely dependen= t on order in algorithm lists (client algorithm order matters), and I belie= ve so is TLS (server algorithm order matters).

The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default, = because the extensions are assumed to be independent. However, I see no rea= son to prevent it from becoming an algorithm list for some purposes, if the= goals of some extensions overlap.

Note that = it takes zero effort to allow for this use; and requires writing unnecessar= y code to prevent.

I'm not enthusiastic a= bout writing unnecessary code to prevent a particular type of use, just to = prevent people doing something in the future. The idea, honestly, seems stu= pid.

> My gut feeling is that you will never need this, = so I wanted to know if you actually
> can provide an example that depends on order.
<= div>
It would have to be two or more extensions with ove= rlapping goals. For example:

1. Extension A a= ttempts to address situation X.

2. Extension = A is flawed in situation Y, which bothers some people.

3. Extension B is developed to addresses situations X+Y. However,= being more complete, it is much more complex than Extension A. Past experi= ence shows that there will be existing servers which will only do Extension= A well. They might implement B, but it will be a hack job.

4. Therefore, Extension B specifies itself as a potential re= placement for Extension A, but allows servers to signal which one they pref= er by controlling the order in which the extensions appear. If both extensi= ons are advertised by both parties, then Extension B is used IF it is liste= d first by the server. Otherwise, if Extension A is listed first, it is use= d.

= Common example - Extension A favored by Li= nux servers, Extension B favored by everyone else. The story of SFTP.


> I think = explaining this in the document would be useful.
> "Penalties" sounds a bit vague.

Added footnote to explain.

denis
=


<= /div>

On Wed, Sep 13, 2017 at 7:1= 2 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote:
>=C2=A0= It is not clear for me from the formatting whether the first
> name-list is sent=C2=A0b= y the client and the second by the server,
> or both lists are always included=C2=A0in the value. I suspect it
> is the former, but can you please clarify?

SSH negotiates compression, integrity, and encryption= algorithms separately for each direction. Both lists are sent by both part= ies. Not just here, but also in KEXINIT.

This is used rarely in practice, but this draft keeps= to the same practice, so as not to bundle a reduction of functionality (i.= e. requiring same compression for both directions) in the same package as a= n extension (i.e. providing a mechanism for delayed activation of compressi= on).

The next draft will include an example of encoding, a= s suggested by Adam. This should make things clearer, even for readers unfa= miliar with SSH.
Yes, I think this will help. If you can list an ex= ample here for both the client side and the server side, that would be grea= t.


>=C2=A01) Sentences like:
> Use of=C2=A0 Receivers MUST tolerate any sequenc= e of bytes; including
> null bytes=C2=A0at = any position; in an unknown extension's extension-value.

Reads fine to me. Still, I changed these to use dashe= s.


>=C2=A0Can you provide an = example of why depending on order
> would be useful? This=C2=A0potentially makes it harder to implement.

It is the nature of an extension mechanism that it in= tends to be open to unforeseen circumstances. If we could come up with exam= ples for all possible future uses, extensions would not be required.=

For this reason, I would prefer if you can demonstrat= e how allowing for this possibility makes anything harder to implement. In = my implementation experience, it doesn't.
I implemented multiple capability negotiation fram= eworks and very few of them (at the moment I can't think of any, actual= ly) have dependencies on order. Dealing with one element at a time seems a = bit simpler.

My gut feeling is that you will never need this, so I wanted to know i= f you actually can provide an example that depends on order.

>= =C2=A0In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO.
> It would be=C2=A0less co= nfusing if you used the latter consistently everywhere.

This doesn't just go for EXT_INFO, it also goes f= or KEXINIT, NEWKEYS, NEWCOMPRESS, and USERAUTH_SUCCESS.

OK, I changed this to use the SSH_MSG_ prefix always.=
Thank you.


>=C2=A0=C2=A0 This extension is sent by the server= , and contains a list of public
> =C2=A0 key algorithms that the server is able to= process as part of a
> =C2=A0 "publickey" authentication requ= est. If a client sends this extension,
> =C2=A0 the server MAY ignore it, and MAY disconn= ect.
>
> Why would the client disconnect when seeing this= extension? Does it mean it is
> broken?
>=C2=A0
> Also, as the client can always disconnect at any= point, why mentioning this
> here?

I believe you have misread the text in this case. It = should be clear from the above quoted snippet.
Oh, do you mean that this is never supposed to be = sent by the client? In this case, yes, I misread it. Never mind.
<= span>


>=C2=A0Can you elaborate o= n what do you mean by "authentication penalties"
> in this=C2=A0context?

SSH servers commonly implement some way of locking ou= t or throttling IP addresses that make frequent login attempts, so as to de= ter brute force password guessing, username guessing, and similar undesired= behaviors.

Some servers apply such penalties to clients that att= empt to use an unknown public key algorithm (e.g. "rsa-sha2-256")= . This can result in the client's IP address being locked out.

The "server-sig-algs" extension provides a = way for the client to know that the server supports e.g. "rsa-sha2-256= " before it attempts to use it, to avoid a potential IP lockout.
I think explaining this in the document would be u= seful. "Penalties" sounds a bit vague.

On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <aamelnikov@fastma= il.fm> wrote:
Alexey Melnikov has entered the = following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all=
email addresses included in the To and CC lines. (Feel free to cut th= is
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a good and useful document. I have some minor comme= nts I
would like to discuss:

3.2.=C2=A0 "delay-compression"

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

=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-com= pression"
=C2=A0 =C2=A0 string:
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_cl= ient_to_server
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_se= rver_to_client

It is not clear for me from the formatting whether the first name-lis= t is sent
by the client and the second by the server, or both lists are always = included
in the value. I suspect it is the former, but can you please clarify?=


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Sentences like:
=C2=A0 Use of=C2=A0 Receivers MUST tolerate any sequence of bytes; in= cluding null bytes
=C2=A0 at any position; in an unknown extension's extension-value= .
or
=C2=A0In particular, applications MUST=C2=A0 tolerate any sequence of= bytes; including
=C2=A0null bytes at any position;=C2=A0 in an unknown extension's= extension-value.

Use of punctuation is not my strongest point, but I am reasonably cer= tain that
use of ";" is not correct here. I think you should use (). = Otherwise these
sentences are reading as a list of 3 things, yet in both cases the 3r= d is a
continuation of the 1st.

2) In Section 2.5:

=C2=A0The relative order in which extensions appear in an
=C2=A0 EXT_INFO message MUST be ignored by default; but an extension = MAY
=C2=A0 specify that the order matters for that extension, in a specif= ic way.

Can you provide an example of why depending on order would be useful?= This
potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It wo= uld be
less confusing if you used the latter consistently everywhere.

3) In 3.1:

=C2=A0 This extension is sent by the server, and contains a list of p= ublic
=C2=A0 key algorithms that the server is able to process as part of a=
=C2=A0 "publickey" authentication request. If a client send= s this extension,
=C2=A0 the server MAY ignore it, and MAY disconnect.

Why would the client disconnect when seeing this extension? Does it m= ean it is
broken?

Also, as the client can always disconnect at any point, why mentionin= g this
here?

=C2=A0 If a server does not send this extension, a client MUST NOT ma= ke any
=C2=A0 assumptions about the server's public key algorithm suppor= t, and MAY
=C2=A0 proceed with authentication requests using trial and error. No= te that
=C2=A0 implementations are known to exist that apply authentication p= enalties
=C2=A0 if the client attempts to use an unexpected public key algorit= hm.

Can you elaborate on what do you mean by "authentication penalti= es" in this
context?


_______________________________________________
Curdle mailing list



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

--001a113cf39c02420305592557b4-- From nobody Thu Sep 14 06:02: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 45896133010; Thu, 14 Sep 2017 06:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 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, HTTPS_HTTP_MISMATCH=1.989, 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 3UIdHR7sp7d3; Thu, 14 Sep 2017 06:02:36 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2160B132F65; Thu, 14 Sep 2017 06:02:35 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id 80so7647236lfy.4; Thu, 14 Sep 2017 06:02:35 -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=OcXhytjuIt7FVvwAHEiuLi5H8qM1v/7SuHb7hBHGn9s=; b=M2ZBvsmGPZJ1mgkgR3hB+rjHcWdiymdpIfYhmNVaRrSv6Tf84v/6aZ6uDm4IKftBI1 JblNHFFsKMsRpMvpDWdbsk2Z9w71wAF7GhHgZ66BzX/xCCP+VjDJM4bP1K29oKO0S8Ru vqRdQaPyZbeb0RyIiiGZww27kMvj9zSNDcA5W4pR9iE0gntiV3UbDb8tbHY3o2RJNkVh V2JHOLVYey3+b3ynfafyjDbEq8GyHYlQMpiCgvbHmZMlzzVPUwsaKh6vwxp3Xuxtz56T v8Yl8tn717RAs8JCAoxzKFOCjQ9mQAjJPjb8cxBtV/tNRUrfSax3NLxYL+i/N6J3KXwe ZUcA== 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=OcXhytjuIt7FVvwAHEiuLi5H8qM1v/7SuHb7hBHGn9s=; b=NhXjGDhHdSjZUdErFKb+UBZuvpoxn83qklPQLkw3M900mkR7zhGBCBy5JSST8ItUgJ n2aRXM0XBb9Sv4LAlHD3Jb7aw9DKmoAqHSO/Oms079jYYRrKUZAsIwXcy0Tm5ZB2s3Gl /RpjFO36bHHyXMRVsgVfMPFW7xAPEBGkBEbQ6QgdkWl6t1vk+/IFb3jzMLFywJOaqsaW qOXkqc3xuMZGNlL9jz+v8YrDgjmspPVkcTqEPL3sWqHC80zhef3LcKoCLbcAu6Khr9oo TMdvhQFMx2amgBslGcA6FSFe/V9Q1hhX3BvNAgcC+Rv3cuwmlQB071VIIizOxUw3vGEP x2nw== X-Gm-Message-State: AHPjjUjri4nfLdF4QqQVbBHja4k2oeLkiek5Xv50I/jozM5w1k7c3XKL azESlNnAjrJSIM0XCYi6NZ6tP+40SkhTjaAnMxw= X-Google-Smtp-Source: AOwi7QATbaTcBYVbpnCKIV62Gnu2gYv72gaeJTihxKwNubjLziqHNPNOFS7d4AiBwnVnFA/aYuH3+WJ5QnxzsHLnthU= X-Received: by 10.46.3.1 with SMTP id 1mr11723ljd.147.1505394153313; Thu, 14 Sep 2017 06:02:33 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Thu, 14 Sep 2017 06:02:32 -0700 (PDT) In-Reply-To: References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Thu, 14 Sep 2017 09:02:32 -0400 X-Google-Sender-Auth: nlPlZJUmfgtG9AortK8misTWagM Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , curdle , "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , curdle , The IESG Content-Type: multipart/alternative; boundary="089e082756b8c15b12055925e3c0" Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 13:02:43 -0000 --089e082756b8c15b12055925e3c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mirja for raising this question. I agree that "Historic" may be better than "Obsoleted" as far as the content of RFC4757 is concerned. I believe that the "Obsolete" status is mostly motivated by the usage of 3DES. Maybe the ambiguity is that RFC4757 is both a protocol description as well as reference to use the protocol. RFC4757 is referenced by the IANA [1]. For that reason obsoleting the document would create a link between the old reference and the new one. That is 1) RFC4757 clearly mentions the current RFC is expected to be considered. This means that if you folllow RFC4757 you cannot ignore teh new RFC which says do not use it. A similar question could be what reference should be placed on the IANA page. I discussed this aspect with the IANA say that implementation description or the document obsoleting the code point can be used. If a discussion happen I believe that would be good to provide guidance. I am happy with any decision made by the IESG and happy to help providing such guidance. [1] https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.tx= t On Thu, Sep 14, 2017 at 8:19 AM, Salz, Rich wrote: > Isn=E2=80=99t the IESG free to take up the recommendation and state-chang= e at any > time? > > > > I think this document clearly says DON=E2=80=99T DO THIS in big flashing = letters > and that all signals for this are needed. > > > > > > *From: *Eric Rescorla > *Date: *Thursday, September 14, 2017 at 8:16 AM > *To: *Mirja Kuehlwind > *Cc: *"draft-ietf-curdle-des-des-des-die-die-die@ietf.org" < > draft-ietf-curdle-des-des-des-die-die-die@ietf.org>, Daniel Migault < > daniel.migault@ericsson.com>, "curdle@ietf.org" , " > curdle-chairs@ietf.org" , "iesg@ietf.org" < > iesg@ietf.org> > *Subject: *Re: [Curdle] Mirja K=C3=BChlewind's Discuss on > draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS) > > > > The situation here is that the algorithms are still in use, but we want > people to stop using them. > > > > Based on Mirja's comments, it seems like neither of these is exactly on > point. Personally, I'm happy with any, all, or none of these actions. > > > > Given this situation, what do others think? > > > > -Ekr > > > > > > On Mon, Sep 4, 2017 at 6:47 AM, Mirja K=C3=BChlewind > wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-curdle-des-des-des-die-die-die-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des- > des-die-die-die/ > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is mainly a processing question, so probably more for the IESG to > discuss > than the authors: > > I understand the intention of obsoleting RFC4757 to declare that the > algorithms > described should not be used anymore, however, rfc4757 is an informationa= l > implementation description which is probably still deployed. Obsoleting a= n > informational implementation description seems a bit weird. Just would > like to > double-check with the rest of the IESG if that action appropriate...? > > Also obsoleting and moving to historic is not the same thing. The documen= t > says: > "This document recommends the reclassification of [RFC4757] as Historic." > One of the two actions (obsoleting or moving to historic) is enough. Whil= e > I > think moving to historic might actually be more appropriate than > obsoleting an > implementation description, it should only be moved to historic if this i= s > not > used and deployed anymore. Also moving to historic also requires a status > change action. > > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --089e082756b8c15b12055925e3c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mirja for raising this question. I agree that = "Historic" may be better than "Obsoleted" as far as the= content of RFC4757 is concerned. I believe that the "Obsolete" s= tatus is mostly motivated by the usage of 3DES. Maybe the ambiguity is that= RFC4757 is both a protocol description as well as reference to use the pro= tocol. RFC4757 is referenced by the IANA [1]. For that reason obsoleting th= e document would create a link between the old reference and the new one. T= hat is 1) RFC4757 clearly mentions the current RFC is expected to be consid= ered. This means that if you folllow RFC4757 you cannot ignore teh new RFC = which says do not use it.

A similar question could be what referenc= e should be placed on the IANA page. I discussed this aspect with the IANA = say that implementation description or the document obsoleting the code poi= nt can be used. =C2=A0

If a discussion happen I believe that = would be good to provide guidance. I am happy with any decision made by the= IESG and happy to help providing such guidance.=C2=A0

On Thu, Sep 14, 2017 at 8:19 AM, Salz, Rich <rsalz@ak= amai.com> wrote:

Isn=E2=80=99t the IESG free to take up the recommendation and state-change= at any time?

=C2=A0

I think this document clearly says DON=E2=80=99T DO THIS in big flashing l= etters and that all signals for this are needed.

=C2=A0

=C2=A0

F= rom: Eric Rescorla <ekr@rtfm.com>
Date: Thursday, September 14, 2017 at 8:16 AM
To: Mirja Kuehlwind <ietf@kuehlewind.net>
Cc: "draft-ietf-curdle-des-des-des-die-die-di= e@ietf.org" <draft-ietf-curdle-des-des-des-di= e-die-die@ietf.org>, Daniel Migault <daniel.migault@ericsson.com>, &= quot;curdle@ietf.org" <curdle@ie= tf.org>, "curdle-chairs@ietf.org" <curdle-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org&g= t;
Subject: Re: [Curdle] Mirja K=C3=BChlewind's Discuss on draft-ie= tf-curdle-des-des-des-die-die-die-04: (with DISCUSS)

=C2=A0

The situation here is that the algorithms are still = in use, but we want people to stop using them.

=C2=A0

Based on Mirja's comments, it seems like neither= of these is exactly on point. Personally, I'm happy with any, all, or = none of these actions.

=C2=A0

Given this situation, what do others think?

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Mon, Sep 4, 2017 at 6:47 AM, Mirja K=C3=BChlewind= <ietf@kuehlewi= nd.net> wrote:

Mirja K=C3=BChlewind = has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatrac= ker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/


-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is mainly a processing question, so probably more for the IESG to disc= uss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algori= thms
described should not be used anymore, however, rfc4757 is an informational<= br> implementation description which is probably still deployed. Obsoleting an<= br> informational implementation description seems a bit weird. Just would like= to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document = says:
"This document recommends the reclassification of [RFC4757] as Histori= c."
One of the two actions (obsoleting or moving to historic) is enough. While = I
think moving to historic might actually be more appropriate than obsoleting= an
implementation description, it should only be moved to historic if this is = not
used and deployed anymore. Also moving to historic also requires a status change action.



=C2=A0


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

--089e082756b8c15b12055925e3c0-- From nobody Thu Sep 14 06:07:22 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 1232312EC30; Thu, 14 Sep 2017 06:07:21 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539444102.12582.8908916637122645610@ietfa.amsl.com> Date: Thu, 14 Sep 2017 06:07:21 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-13.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, 14 Sep 2017 13:07:21 -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 WG of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-13.txt Pages : 13 Date : 2017-09-14 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-13 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 Sep 14 06:08: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 092F5132F65; Thu, 14 Sep 2017 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 o2AfbTCEUaFG; Thu, 14 Sep 2017 06:08: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 DFBA3133010; Thu, 14 Sep 2017 06:08:21 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id k23so351253lfi.11; Thu, 14 Sep 2017 06:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oMN0dXKAU7jacfnGwXmQ7k9kDXM5Y+y+c0LJJyaue9A=; b=GIdmpY1jDpXqk8OZNuXgxrKinqxub8eC2YOP4PLBDQRL1fNbw/qydzPuoGtlZSa5Lm 1Izg2HhZOw2KL9d3NbI+L01b31ElT11oLtVB/Gh6LQ5rvdTfblNi5ya94R1R0zKRzu4v z0IjANGUXfJ0o7yQHPdDAD6hfom3xqZz12FVYiDnGT0qFwjKDe7KRFTzU/DqDRN08hR3 VTsqvo+8md+5fX5KJZMCkZyf8aTLjTqLRO9zVNqOYiTh72ekx8hBRAOfqMzGnZqVSpkT 9Wgv0XzJi26yK+agqrfUS7BDwj/8nZMwDnuxpW5ogh82zjmHM2U94FA3iWEwzpY95cTl D63A== 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=oMN0dXKAU7jacfnGwXmQ7k9kDXM5Y+y+c0LJJyaue9A=; b=EP9d1DOCreDTeMeil/Wq2w0RWAcTfIrioLQ3sgtyUH7gtZjRnheMB3POe6g3jYeyr0 73N2YA/Fv6yLKFjV/OUwySiHs0JRbK8lGqloM3tGYFdJ99uZXGH7RINvaQgLD0JH+0OV 4C8cVulbDosI8f0vU0wIrPimxVYUaEZjUaTEzgKxTXeNUmNw8xX7RU0mfJ+NV0snhOjQ +UtRZZXw7czRkCGhIyq7WG6/9mV2F1siT0nlsqemAuMGGy1qKRqsVMsodWTNPDddzdJ1 /pxFPlfHZBe74p5LXLOmMVW9Ya13+28cEO/uHewKI5YmUlpTbquZJyfrav9t24Py/2Gy c6bw== X-Gm-Message-State: AHPjjUgsiRRS9WvV6q/2nXXVTCsDbPM7UKi2LN0DAQpqGA8DrxgiUC5U TFRFfELzIDpg/tDZ9G3PMD67eoPlbjDWZikAArE= X-Google-Smtp-Source: ADKCNb556/NZ7jWZnO/wxAcbBgV0baDh8wvPLHw4IVzU3WDGUDB9rYsL+hSK6smXvd7sKTsSbXyKHDVlX1muYVMRciE= X-Received: by 10.46.0.160 with SMTP id e32mr9066162lji.106.1505394500195; Thu, 14 Sep 2017 06:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Thu, 14 Sep 2017 06:08:19 -0700 (PDT) In-Reply-To: References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> From: denis bider Date: Thu, 14 Sep 2017 07:08:19 -0600 Message-ID: To: Eric Rescorla Cc: Alexey Melnikov , Daniel Migault , curdle , curdle-chairs , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a1142bbc66e5993055925f86b" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 13:08:26 -0000 --001a1142bbc66e5993055925f86b Content-Type: text/plain; charset="UTF-8" Submitted. :-) On Thu, Sep 14, 2017 at 6:22 AM, Eric Rescorla wrote: > It sounds like we have resolutions to both Adam's and Alexey's issues. > Denis, can you please submit a new draft and then (assuming it is > satisfactory to them) Adam and Alexey can clear. > > -Ekr > > > On Wed, Sep 13, 2017 at 6:48 AM, denis bider > wrote: > >> > If you can list an example here for both the client side and the >> server side, that would be great. >> >> There is no difference between what the two send. Added a line to explain >> that as well. >> >> >> > capability negotiation frameworks and very few of them (at the moment >> > I can't think of any, actually) have dependencies on order >> >> Not sure if I understand you correctly, but SSH is completely dependent >> on order in algorithm lists (client algorithm order matters), and I believe >> so is TLS (server algorithm order matters). >> >> The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default, >> because the extensions are assumed to be independent. However, I see no >> reason to prevent it from becoming an algorithm list for some purposes, if >> the goals of some extensions overlap. >> >> Note that it takes zero effort to allow for this use; and requires >> writing unnecessary code to prevent. >> >> I'm not enthusiastic about writing unnecessary code to prevent a >> particular type of use, just to prevent people doing something in the >> future. The idea, honestly, seems stupid. >> >> >> > My gut feeling is that you will never need this, so I wanted to know >> if you actually >> > can provide an example that depends on order. >> >> It would have to be two or more extensions with overlapping goals. For >> example: >> >> 1. Extension A attempts to address situation X. >> >> 2. Extension A is flawed in situation Y, which bothers some people. >> >> 3. Extension B is developed to addresses situations X+Y. However, being >> more complete, it is much more complex than Extension A. Past experience >> shows that there will be existing servers which will only do Extension A >> well. They might implement B, but it will be a hack job. >> >> 4. Therefore, Extension B specifies itself as a potential replacement for >> Extension A, but allows servers to signal which one they prefer by >> controlling the order in which the extensions appear. If both extensions >> are advertised by both parties, then Extension B is used IF it is listed >> first by the server. Otherwise, if Extension A is listed first, it is used. >> >> Common example - Extension A favored by Linux servers, Extension B >> favored by everyone else. The story of SFTP. >> >> >> > I think explaining this in the document would be useful. >> > "Penalties" sounds a bit vague. >> >> Added footnote to explain. >> >> denis >> >> >> >> >> On Wed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov >> wrote: >> >>> On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote: >>> >>> > It is not clear for me from the formatting whether the first >>> > name-list is sent by the client and the second by the server, >>> > or both lists are always included in the value. I suspect it >>> > is the former, but can you please clarify? >>> >>> SSH negotiates compression, integrity, and encryption algorithms >>> separately for each direction. Both lists are sent by both parties. Not >>> just here, but also in KEXINIT. >>> >>> This is used rarely in practice, but this draft keeps to the same >>> practice, so as not to bundle a reduction of functionality (i.e. requiring >>> same compression for both directions) in the same package as an extension >>> (i.e. providing a mechanism for delayed activation of compression). >>> >>> The next draft will include an example of encoding, as suggested by >>> Adam. This should make things clearer, even for readers unfamiliar with SSH. >>> >>> Yes, I think this will help. If you can list an example here for both >>> the client side and the server side, that would be great. >>> >>> >>> > 1) Sentences like: >>> > Use of Receivers MUST tolerate any sequence of bytes; including >>> > null bytes at any position; in an unknown extension's extension-value. >>> >>> Reads fine to me. Still, I changed these to use dashes. >>> >>> >>> > Can you provide an example of why depending on order >>> > would be useful? This potentially makes it harder to implement. >>> >>> It is the nature of an extension mechanism that it intends to be open to >>> unforeseen circumstances. If we could come up with examples for all >>> possible future uses, extensions would not be required. >>> >>> For this reason, I would prefer if you can demonstrate how allowing for >>> this possibility makes anything harder to implement. In my implementation >>> experience, it doesn't. >>> >>> I implemented multiple capability negotiation frameworks and very few of >>> them (at the moment I can't think of any, actually) have dependencies on >>> order. Dealing with one element at a time seems a bit simpler. >>> >>> My gut feeling is that you will never need this, so I wanted to know if >>> you actually can provide an example that depends on order. >>> >>> > In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. >>> > It would be less confusing if you used the latter consistently >>> everywhere. >>> >>> This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS, >>> NEWCOMPRESS, and USERAUTH_SUCCESS. >>> >>> OK, I changed this to use the SSH_MSG_ prefix always. >>> >>> Thank you. >>> >>> >>> > This extension is sent by the server, and contains a list of public >>> > key algorithms that the server is able to process as part of a >>> > "publickey" authentication request. If a client sends this extension, >>> > the server MAY ignore it, and MAY disconnect. >>> > >>> > Why would the client disconnect when seeing this extension? Does it >>> mean it is >>> > broken? >>> > >>> > Also, as the client can always disconnect at any point, why mentioning >>> this >>> > here? >>> >>> I believe you have misread the text in this case. It should be clear >>> from the above quoted snippet. >>> >>> Oh, do you mean that this is never supposed to be sent by the client? In >>> this case, yes, I misread it. Never mind. >>> >>> >>> > Can you elaborate on what do you mean by "authentication penalties" >>> > in this context? >>> >>> SSH servers commonly implement some way of locking out or throttling IP >>> addresses that make frequent login attempts, so as to deter brute force >>> password guessing, username guessing, and similar undesired behaviors. >>> >>> Some servers apply such penalties to clients that attempt to use an >>> unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the >>> client's IP address being locked out. >>> >>> The "server-sig-algs" extension provides a way for the client to know >>> that the server supports e.g. "rsa-sha2-256" before it attempts to use it, >>> to avoid a potential IP lockout. >>> >>> I think explaining this in the document would be useful. "Penalties" >>> sounds a bit vague. >>> >>> On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov >> > wrote: >>> >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-curdle-ssh-ext-info-12: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/stat >>> ement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is generally a good and useful document. I have some minor comments >>> I >>> would like to discuss: >>> >>> 3.2. "delay-compression" >>> >>> This extension MAY be sent by both parties as follows: >>> >>> string "delay-compression" >>> string: >>> name-list compression_algorithms_client_to_server >>> name-list compression_algorithms_server_to_client >>> >>> It is not clear for me from the formatting whether the first name-list >>> is sent >>> by the client and the second by the server, or both lists are always >>> included >>> in the value. I suspect it is the former, but can you please clarify? >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> 1) Sentences like: >>> Use of Receivers MUST tolerate any sequence of bytes; including null >>> bytes >>> at any position; in an unknown extension's extension-value. >>> or >>> In particular, applications MUST tolerate any sequence of bytes; >>> including >>> null bytes at any position; in an unknown extension's extension-value. >>> >>> Use of punctuation is not my strongest point, but I am reasonably >>> certain that >>> use of ";" is not correct here. I think you should use (). Otherwise >>> these >>> sentences are reading as a list of 3 things, yet in both cases the 3rd >>> is a >>> continuation of the 1st. >>> >>> 2) In Section 2.5: >>> >>> The relative order in which extensions appear in an >>> EXT_INFO message MUST be ignored by default; but an extension MAY >>> specify that the order matters for that extension, in a specific way. >>> >>> Can you provide an example of why depending on order would be useful? >>> This >>> potentially makes it harder to implement. >>> >>> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would >>> be >>> less confusing if you used the latter consistently everywhere. >>> >>> 3) In 3.1: >>> >>> This extension is sent by the server, and contains a list of public >>> key algorithms that the server is able to process as part of a >>> "publickey" authentication request. If a client sends this extension, >>> the server MAY ignore it, and MAY disconnect. >>> >>> Why would the client disconnect when seeing this extension? Does it mean >>> it is >>> broken? >>> >>> Also, as the client can always disconnect at any point, why mentioning >>> this >>> here? >>> >>> If a server does not send this extension, a client MUST NOT make any >>> assumptions about the server's public key algorithm support, and MAY >>> proceed with authentication requests using trial and error. Note that >>> implementations are known to exist that apply authentication penalties >>> if the client attempts to use an unexpected public key algorithm. >>> >>> Can you elaborate on what do you mean by "authentication penalties" in >>> this >>> context? >>> >>> >>> _______________________________________________ >>> 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 >> >> > --001a1142bbc66e5993055925f86b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Submitted. :-)

On Thu, Sep 14, 2017 at 6:22 AM, Eric Rescorla <ekr@rtfm.co= m> wrote:
= It sounds like we have resolutions to both Adam's and Alexey's issu= es. Denis, can you please submit a new draft and then (assuming it is satis= factory to them) Adam and Alexey can clear.

-Ekr


On Wed, Sep 13, 2017 at 6:48 AM, = denis bider <denisbider.ietf@gmail.com> wrote:
>=C2=A0If you can list an example here for both the client s= ide and the server side, that would be great.

There is no difference between what the two send. Added a line to explain= that as well.

=

>=C2=A0capability negotiation frameworks and very few of them (at the moment=
> I can't think o= f any, actually) have dependencies on order

Not sure if I understand you correctly, but SSH is completely depende= nt on order in algorithm lists (client algorithm order matters), and I beli= eve so is TLS (server algorithm order matters).

The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default,= because the extensions are assumed to be independent. However, I see no re= ason to prevent it from becoming an algorithm list for some purposes, if th= e goals of some extensions overlap.

Note that= it takes zero effort to allow for this use; and requires writing unnecessa= ry code to prevent.

<= /span>
I'm not enthusiastic = about writing unnecessary code to prevent a particular type of use, just to= prevent people doing something in the future. The idea, honestly, seems st= upid.


> My gut feeling is that you will never need this, so I wante= d to know if you actually
> can provide an example that depends on order.

It would have to be two or more extensions with overlapping g= oals. For example:

1. Extension A attempts to= address situation X.
2. Extension A is flawe= d in situation Y, which bothers some people.

3. Extension B is developed to addresses situations X+Y. However, being m= ore complete, it is much more complex than Extension A. Past experience sho= ws that there will be existing servers which will only do Extension A well.= They might implement B, but it will be a hack job.

4. Therefore, Extension B specifies itself as a potential replacemen= t for Extension A, but allows servers to signal which one they prefer by co= ntrolling the order in which the extensions appear. If both extensions are = advertised by both parties, then Extension B is used IF it is listed first = by the server. Otherwise, if Extension A is listed first, it is used.

Common example - Extension A favored by Linux serv= ers, Extension B favored by everyone else. The story of SFTP.
<= span>


> I think explaining this in = the document would be useful.
> "Penalties" sounds a bit vague.

Added footnote to explain.

denis




On Wed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote:
>=C2=A0It is not clear for me from the formatting whether th= e first
> name-list is sent=C2=A0by the client and the second by = the server,
> or both lists are always i= ncluded=C2=A0in the value. I = suspect it
> is the former, but can you= please clarify?

SSH negotiates compression, int= egrity, and encryption algorithms separately for each direction. Both lists= are sent by both parties. Not just here, but also in KEXINIT.

This is used rarely in practice= , but this draft keeps to the same practice, so as not to bundle a reductio= n of functionality (i.e. requiring same compression for both directions) in= the same package as an extension (i.e. providing a mechanism for delayed a= ctivation of compression).

The next draft will include an = example of encoding, as suggested by Adam. This should make things clearer,= even for readers unfamiliar with SSH.
Yes, I think this will help. If you can list an ex= ample here for both the client side and the server side, that would be grea= t.


>=C2=A01) Sentences like:
> Use of=C2=A0 Receivers MUS= T tolerate any sequence of bytes; including
> null bytes=C2=A0at any position; in an unknown ext= ension's extension-value.

Reads fine to me. Still, I chan= ged these to use dashes.


>=C2=A0Can you provide an example of why depending on ord= er
> would be useful? This=C2= =A0potentially makes it harde= r to implement.

It is the nature of an extensio= n mechanism that it intends to be open to unforeseen circumstances. If we c= ould come up with examples for all possible future uses, extensions would n= ot be required.

For this reason, I would prefer= if you can demonstrate how allowing for this possibility makes anything ha= rder to implement. In my implementation experience, it doesn't.<= br>
I implemented multiple capability negotiation fram= eworks and very few of them (at the moment I can't think of any, actual= ly) have dependencies on order. Dealing with one element at a time seems a = bit simpler.

My gut feeling is that you will never need this, so I wanted to know i= f you actually can provide an example that depends on order.

>=C2=A0In several places you use EXT_INFO instead of SS= H_MSG_EXT_INFO.
> It would be=C2=A0less confusing if you used the latter = consistently everywhere.

This doesn't just go for EX= T_INFO, it also goes for KEXINIT, NEWKEYS, NEWCOMPRESS, and USERAUTH_SUCCES= S.

OK, I changed this to use the S= SH_MSG_ prefix always.
Thank you.


>=C2=A0=C2=A0 This extension= is sent by the server, and contains a list of public
> =C2=A0 key algorithms that= the server is able to process as part of a
> =C2=A0 "publickey&quo= t; authentication request. If a client sends this extension,
> =C2=A0 the server MAY igno= re it, and MAY disconnect.
>
> Why would the client disco= nnect when seeing this extension? Does it mean it is
> broken?
>=C2=A0
> Also, as the client can al= ways disconnect at any point, why mentioning this
> here?

I believe you have misread the = text in this case. It should be clear from the above quoted snippet.=
Oh, do you mean that this is never supposed to be = sent by the client? In this case, yes, I misread it. Never mind.
<= span>


>=C2=A0Can you elaborate on what do you mean by "aut= hentication penalties"
> in this=C2=A0context?

SSH servers commonly implement = some way of locking out or throttling IP addresses that make frequent login= attempts, so as to deter brute force password guessing, username guessing,= and similar undesired behaviors.

Some servers apply such penalti= es to clients that attempt to use an unknown public key algorithm (e.g. &qu= ot;rsa-sha2-256"). This can result in the client's IP address bein= g locked out.

The "server-sig-algs"= extension provides a way for the client to know that the server supports e= .g. "rsa-sha2-256" before it attempts to use it, to avoid a poten= tial IP lockout.
I think explaining this in the document would be u= seful. "Penalties" sounds a bit vague.

On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the = following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Discuss

When responding, please keep the subject line intact and reply to all=
email addresses included in the To and CC lines. (Feel free to cut th= is
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a good and useful document. I have some minor comme= nts I
would like to discuss:

3.2.=C2=A0 "delay-compression"

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

=C2=A0 =C2=A0 string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"delay-com= pression"
=C2=A0 =C2=A0 string:
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_cl= ient_to_server
=C2=A0 =C2=A0 =C2=A0 name-list=C2=A0 =C2=A0 compression_algorithms_se= rver_to_client

It is not clear for me from the formatting whether the first name-lis= t is sent
by the client and the second by the server, or both lists are always = included
in the value. I suspect it is the former, but can you please clarify?=


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Sentences like:
=C2=A0 Use of=C2=A0 Receivers MUST tolerate any sequence of bytes; in= cluding null bytes
=C2=A0 at any position; in an unknown extension's extension-value= .
or
=C2=A0In particular, applications MUST=C2=A0 tolerate any sequence of= bytes; including
=C2=A0null bytes at any position;=C2=A0 in an unknown extension's= extension-value.

Use of punctuation is not my strongest point, but I am reasonably cer= tain that
use of ";" is not correct here. I think you should use (). = Otherwise these
sentences are reading as a list of 3 things, yet in both cases the 3r= d is a
continuation of the 1st.

2) In Section 2.5:

=C2=A0The relative order in which extensions appear in an
=C2=A0 EXT_INFO message MUST be ignored by default; but an extension = MAY
=C2=A0 specify that the order matters for that extension, in a specif= ic way.

Can you provide an example of why depending on order would be useful?= This
potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It wo= uld be
less confusing if you used the latter consistently everywhere.

3) In 3.1:

=C2=A0 This extension is sent by the server, and contains a list of p= ublic
=C2=A0 key algorithms that the server is able to process as part of a=
=C2=A0 "publickey" authentication request. If a client send= s this extension,
=C2=A0 the server MAY ignore it, and MAY disconnect.

Why would the client disconnect when seeing this extension? Does it m= ean it is
broken?

Also, as the client can always disconnect at any point, why mentionin= g this
here?

=C2=A0 If a server does not send this extension, a client MUST NOT ma= ke any
=C2=A0 assumptions about the server's public key algorithm suppor= t, and MAY
=C2=A0 proceed with authentication requests using trial and error. No= te that
=C2=A0 implementations are known to exist that apply authentication p= enalties
=C2=A0 if the client attempts to use an unexpected public key algorit= hm.

Can you elaborate on what do you mean by "authentication penalti= es" in this
context?


_______________________________________________
Curdle mailing list



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


--001a1142bbc66e5993055925f86b-- From nobody Thu Sep 14 06:26: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 BCD6112421A; Thu, 14 Sep 2017 06:26:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539560076.12633.8635092915362137229.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 06:26:40 -0700 Archived-At: Subject: [Curdle] Alexey Melnikov's Yes on draft-ietf-curdle-ssh-ext-info-13: (with COMMENT) 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, 14 Sep 2017 13:26:41 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS and comments. From nobody Thu Sep 14 06:45: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 9765F132D49 for ; Thu, 14 Sep 2017 06:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So1V0o5OZ-4r for ; Thu, 14 Sep 2017 06:45:43 -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 C4925132355 for ; Thu, 14 Sep 2017 06:45:43 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id e189so515561ioa.4 for ; Thu, 14 Sep 2017 06:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/AGtSvD3Gt2ZVqKvOD8kCddIeZFLRMpAmbt0rZ/dxY8=; b=mxbzgH05+TRlA3YsuuO2DOCtvez/8TRDW5DoE3JS6GS1XRrvCJGPOCu1NUUf45R/k8 tMMeh7QGwrZivCDoekehQvPFTcWj/jplR+G37E89bl+ftfRt7hXk1mTSxl0Yw3HUYjtt MDsV8PoWzIwBDg2bjbsUkPCzRIGbxu39DqS/ZxMlM51roSbOl+ZgdVO76bcAADcVw+EB zg0AbtHOWi6Gi88nzYS5CLwkPHQAkjaeMrUjfr2YrS42iasUiJOnthE4nZDqOCh0kog1 wjC8csLhKjzedaYog+vOc55Fv8JdZbI1+jxpyaLlcWLxR9urfeNJWEVbCTY941tAMeW9 12gQ== 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=/AGtSvD3Gt2ZVqKvOD8kCddIeZFLRMpAmbt0rZ/dxY8=; b=c9pyGGtUgB/xGK3iOAvgcyRdSBKnn8B7Q1tzDDAgmuHdByMwZUpiE8wgFXmh034bb/ +w5s7UJInXITNwUikD8DC1TFs+B7avXN+l7963XtBmncUR7qc/GeBq+wknA/LfOcLyP0 rFW07Tf5nqMfuI2Q6juyVs0KMRslx48/QVdxuWpreQeCDCoI/v0V+8+wHoziJ/bF62Ol 6IKYVg3P5Mh2r4I/rWzDeXQdHnIOn0xx4t2CZMsk9rH5uP4wYCuQXZjZOngRwLmH5RIt aFLOeVChXsL6IYZyaDVHBLsOctBqWt/xW7kegMoZrvPH2FRrc0NXUpUPUfORSyKlPyW2 PgGw== X-Gm-Message-State: AHPjjUiRAC/zKVyk6amtbdzXgmyljPGJePyJIoP++GGK/NXkbGP4bM0l lIGU+s6fKe11V9CBAPyLdToL9NTmwu2K22QntegIog== X-Google-Smtp-Source: AOwi7QCOK7CPh3zvDs5gHvV7LEP9iZdE025Pbn7R5mMdb0fy1U8K7vvMVw1MVuZZzNf0Uqn6rbvGkewhof0GzFL1N/w= X-Received: by 10.202.231.139 with SMTP id e133mr20849566oih.218.1505396743062; Thu, 14 Sep 2017 06:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Thu, 14 Sep 2017 06:45:02 -0700 (PDT) In-Reply-To: <150533146908.30532.5312387197836535820.idtracker@ietfa.amsl.com> References: <150533146908.30532.5312387197836535820.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 14 Sep 2017 06:45:02 -0700 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, curdle , curdle , Daniel Migault Content-Type: multipart/alternative; boundary="001a114080841ddaa00559267e03" Archived-At: Subject: Re: [Curdle] Ben Campbell's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 13:45:46 -0000 --001a114080841ddaa00559267e03 Content-Type: text/plain; charset="UTF-8" Hi Curdle folks, Could you please address the SHOULD/MUST issue raised by Ben and Kathleen -Ekr On Wed, Sep 13, 2017 at 12:37 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-curdle-ssh-dh-group-exchange-05: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I share the questions about "SHOULD" vs "MUST". > > - abstract: "insufficient against state-sponsored > actors, and possibly an organization with enough computing resources" > > Should "an" be "any"? (Same question for section 2). > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114080841ddaa00559267e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Curdle folks,

Could you please addre= ss the SHOULD/MUST issue raised by Ben and Kathleen

-Ekr


On Wed, Sep 13, 2017 at 12:37 PM, Ben Campbell <ben@nostr= um.com> wrote:
Ben Campbell= has entered the following ballot position for
draft-ietf-curdle-ssh-dh-group-exchange-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.or= g/doc/draft-ietf-curdle-ssh-dh-group-exchange/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I share the questions about "SHOULD" vs "MUST".

- abstract: "insufficient against state-sponsored
=C2=A0 =C2=A0actors, and possibly an organization with enough computing res= ources"

Should "an" be "any"?=C2=A0 (Same question for section = 2).


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

--001a114080841ddaa00559267e03-- From nobody Thu Sep 14 06:46: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 C55111326DF; Thu, 14 Sep 2017 06:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lH5DzmHcw7wE; Thu, 14 Sep 2017 06:46:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260F61321CB; Thu, 14 Sep 2017 06:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1505396797; x=1506606397; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Yx1erpau9PKUbsxcs/iFgYfQ2XJC/QNtY0Kfrb9dqM0=; b=bsJ8gzlLOBcvXqR0zLsWZ4iuqoJtYtk4fMMuQ3RumJAh6dLwRo0PXnXQ 28jfaSkPDYg3UlC6TPym6SGKcuVqf2KQ68wTM8pfS7+5z9hFQ6qJrdIqC xxyn9ZdibDuYgtlp5xYf7gUGjU8I/xYfu5CuEZ28TCtUmtHlV5/INGDsp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgBoh7pZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD5uJ4N3ixSQRwkiljaCBAolhRcChGYVAQIBAQEBAQEBayiFGQEFIw8?= =?us-ascii?q?BBUEQCxgCAiYCAlcGAQwIAQGKLhCsB4InizUBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RkFgQ6CHYNSgWMrC4JyhEUBEgGDMoJgBYoJlnmHWox4ghOFaINahyGNXIdVgTk?= =?us-ascii?q?1IoECCzIhCBwVhhiBUD42AYY6gjIBAQE?= X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="657462038" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 13:46:32 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8EDkWKB000518; Thu, 14 Sep 2017 13:46:32 GMT To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: curdle-chairs@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-des-des-des-die-die-die@ietf.org, curdle@ietf.org References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.com> Date: Thu, 14 Sep 2017 15:46:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 13:46:40 -0000 On 9/4/2017 3:47 PM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-curdle-des-des-des-die-die-die-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is mainly a processing question, so probably more for the IESG to discuss > than the authors: > > I understand the intention of obsoleting RFC4757 to declare that the algorithms > described should not be used anymore, however, rfc4757 is an informational > implementation description which is probably still deployed. Obsoleting an > informational implementation description seems a bit weird. Just would like to > double-check with the rest of the IESG if that action appropriate...? > > Also obsoleting and moving to historic is not the same thing. The document says: > "This document recommends the reclassification of [RFC4757] as Historic." > One of the two actions (obsoleting or moving to historic) is enough. While I > think moving to historic might actually be more appropriate than obsoleting an > implementation description, Historical makes sense. So does it mean that draft-ietf-curdle-des-des-des-die-die-die is used as "status-change" document in https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html? > it should only be moved to historic if this is not > used and deployed anymore. Where does this condition come from? Regards, B. > Also moving to historic also requires a status > change action. > > > > > . > From nobody Thu Sep 14 07:15: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 7613D132D14; Thu, 14 Sep 2017 07:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sDW-U1DuJ7V; Thu, 14 Sep 2017 07:15:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 907F7132713; Thu, 14 Sep 2017 07:15:38 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8EEFUAi051239 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 09:15:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: denis bider , Eric Rescorla Cc: Daniel Migault , Alexey Melnikov , curdle-chairs , curdle , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> From: Adam Roach Message-ID: <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> Date: Thu, 14 Sep 2017 09:15:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 14:15:39 -0000 On 9/14/17 08:08, denis bider wrote: > Submitted. :-) Thanks. This newest version includes an example, but no further explanation of the encoding. Normative examples that implementors have to reverse engineer are generally bad for interoperability, since implementors have to guess at the handling for corner cases. Could you please add text that describes the encoding itself? It doesn't need to be overly complex, but it does need to be explained. /a From nobody Thu Sep 14 07:29:51 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6313302F for ; Thu, 14 Sep 2017 07:29:46 -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=unavailable 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 lMc_xEJq8r0r for ; Thu, 14 Sep 2017 07:29:44 -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 01FC313302D for ; Thu, 14 Sep 2017 07:29:42 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q11so845571ioe.10 for ; Thu, 14 Sep 2017 07:29: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=WC13p4BXUJTOapL+cb/ewZbs8Ac2YiT6C6CUspkMsf0=; b=qMx/J8EErfLNKkNZpyUKkJ71rHb5Q3qcokc2yWZvV+7N/hhpD/HbEs/WHSqoBzSGDC rxuxqdKaY8mmZ1pYHR7tTpDBeeVrH6cP+dU9+PzCLUvwJOFvPlSngqu9ETTQAlc7X/Zy Ah0tqSYxh3IAWSQid0RZT88RhUWnZmlpvZSDvfBWZFmCKG+Vz/ZYz3Unq4Qp550YHmTo K763npsrx3Me/+hzT7oY+G5Tjy86VU+UMvw7DqT+IyS9FN34xs89de3tmVe4Z/kai3Jy q0X0+VMh2Jfrgxl4Cw0FqYtt499DuO1rtHQt0TBCDFJ1j42q1DqHjr2IrzyJgm/rP357 YsIg== 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=WC13p4BXUJTOapL+cb/ewZbs8Ac2YiT6C6CUspkMsf0=; b=rTPBk4Y8AswR7v88BTPSb8uBPZLKMTn4yeni3f/XZ3eWjW5EoQJFSeRZzLq7Mwt0d/ tj3QvMZaBIinZBPrW001xWjQrfo7sbcwQ8P1+jT3D/nr9pYRhzbld6E11V7U4PpILqRZ Uw0EkGCegOkC3q7v5q1qz7cZEdofFES9c86bfnI2GrnkIpzrMT2OC5vpPTwkwcSt3TaC Zi2mYXUvbDJL51Q1LkReJnEml6Fr/ONmjv0uyq2KQBg4QrB89v+evrX8mDuNMq5iRWBe dcFLqiC1XLWldl7v8ztLa9D4pE167qDC8gJTVzG0Pn5HQlR6Hofn5S0znKF2TF8yJyt0 vRUg== X-Gm-Message-State: AHPjjUhgSlW2Zzs/x4GoJRY6sgaXONIfHNo471sQvSNjzyHkxci+PBW5 moEzhESmBnFUoEJfKVpUnhGJxtsUs+T48BiQOxo8pA== X-Google-Smtp-Source: AOwi7QA86XfuBokTz2pj/emCD1pjQfBZoV8FwTWVKgPqmKoWCbRnOd9WsgI2rENSTT7/nqM2dqsKPmO9v5nmzQEVrBE= X-Received: by 10.202.79.206 with SMTP id d197mr24485121oib.192.1505399381219; Thu, 14 Sep 2017 07:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Thu, 14 Sep 2017 07:29:00 -0700 (PDT) In-Reply-To: <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.com> References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.com> From: Eric Rescorla Date: Thu, 14 Sep 2017 07:29:00 -0700 Message-ID: To: Benoit Claise Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG , draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle , curdle Content-Type: multipart/alternative; boundary="001a1145ed045cede50559271bd1" Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 14:29:46 -0000 --001a1145ed045cede50559271bd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Per today's discussion on the IESG Call, the resolution is: 1. Move 4757 to Historic 2. Include a sentence saying that people still use these algorithms (both, actually) but we are moving things to Historic to tell you not to. OK? -Ekr On Thu, Sep 14, 2017 at 6:46 AM, Benoit Claise wrote: > On 9/4/2017 3:47 PM, Mirja K=C3=BChlewind wrote: > >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-curdle-des-des-des-die-die-die-04: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-d >> es-die-die-die/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is mainly a processing question, so probably more for the IESG to >> discuss >> than the authors: >> >> I understand the intention of obsoleting RFC4757 to declare that the >> algorithms >> described should not be used anymore, however, rfc4757 is an information= al >> implementation description which is probably still deployed. Obsoleting = an >> informational implementation description seems a bit weird. Just would >> like to >> double-check with the rest of the IESG if that action appropriate...? >> >> Also obsoleting and moving to historic is not the same thing. The >> document says: >> "This document recommends the reclassification of [RFC4757] as Historic.= " >> One of the two actions (obsoleting or moving to historic) is enough. >> While I >> think moving to historic might actually be more appropriate than >> obsoleting an >> implementation description, >> > Historical makes sense. So does it mean that draft-ietf-curdle-des-des-de= s-die-die-die > is used as "status-change" document in https://www.ietf.org/iesg/stat > ement/designating-rfcs-as-historic.html? > >> it should only be moved to historic if this is not >> used and deployed anymore. >> > Where does this condition come from? > > Regards, B. > >> Also moving to historic also requires a status >> change action. >> >> >> >> >> . >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1145ed045cede50559271bd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Per today's discussion on the IESG Call, the resolutio= n is:

1. Move=C2=A04757= to Historic
2. Include a= sentence saying that people still use these algorithms (both, actually) bu= t we are moving things to Historic to tell you not to.

OK?
-Ekr=



On Thu, Se= p 14, 2017 at 6:46 AM, Benoit Claise <bclaise@cisco.com> wro= te:
On 9/4/2017 3:47 PM, Mirja K=C3=BChlewind wrote:
Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-curdle-des-des-des-die-die-die/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is mainly a processing question, so probably more for the IESG to disc= uss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algori= thms
described should not be used anymore, however, rfc4757 is an informational<= br> implementation description which is probably still deployed. Obsoleting an<= br> informational implementation description seems a bit weird. Just would like= to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document = says:
"This document recommends the reclassification of [RFC4757] as Histori= c."
One of the two actions (obsoleting or moving to historic) is enough. While = I
think moving to historic might actually be more appropriate than obsoleting= an
implementation description,
Historical makes sense. So does it mean that draft-ietf-curdle-des-des-des-= die-die-die is used as "status-change" document in https://www.ietf.org/iesg/stateme= nt/designating-rfcs-as-historic.html?
it should only be moved to historic if this is not
used and deployed anymore.
 Where does this condition come from?

Regards, B.
Also moving to historic also requires a status
change action.




 .


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

--001a1145ed045cede50559271bd1-- From nobody Thu Sep 14 07:31: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 9D69B132153 for ; Thu, 14 Sep 2017 07:31: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=unavailable 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 2W_O5tJ8gAIh for ; Thu, 14 Sep 2017 07:31:06 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 0E450132713 for ; Thu, 14 Sep 2017 07:31:05 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g32so904887ioj.2 for ; Thu, 14 Sep 2017 07:31:05 -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=A0BQkHvYwpg6m/XDRqa/sboSFrP/I2ma8vfVzE1gz88=; b=Rkthm4ClgXJeGVnRKCEDRd7NPdjSlII4jIHByGRgQD01eLNKKBOSsKLsfT/syCioq+ uWO5ST7CSaa4ZZmwmr0icocnU6kxkMZvKeacAI5hNwFY4SWV1Ip7oxyKb23HlaMo4Ll1 vCONslkrSMzh7agot7OTqTEZIIGnRPTwpwbfMb9gZHagrCX80tloUtY73zxzr4sPRX70 Mew+yH7Elwm7gQcABXh3UIZhGsXiKpJd/jezT3y5W888Mu/vakDOjP3RX+CczFcV/whB M6UkPg5KS0yyF9FBD6aw4kyiudYIouEmcl4FNYiTAt/BeZU48q1Jk89p37/6sfp1j1d2 7L9g== 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=A0BQkHvYwpg6m/XDRqa/sboSFrP/I2ma8vfVzE1gz88=; b=WZPA9XQvQzxw9ehJ6YCvFoBMArjIea2dBxZ0f0Yq/vs4HmsEWx0RxyrrabAlG8MDlQ j5o3WLLRjtQlOEkplbUFsbaaZ6ynqxaaSquTMG5c9nfJexOul52MRTPrg0NBWTNrPlfd YBzrlDjDV5i5NY4yEPmfrKuJgC2sdAI+k989WCNf4/4QALs5AmZ8ZGo2gWixDQyxpqyV yJtd1v1AKDFtZNJgsYjOHP8PBj85jRoaZWnnZd+Tpqp4gLE8+flu3LlkxiNfN0qgz741 HEQvIhWXeZ4wTJenK5Bfd7MMULOma9En4V4XwDZUIJrigOgRntVnPzcZ543gt8tzsFuK BsPg== X-Gm-Message-State: AHPjjUiBNXtNs96jfbHjYm+yvcMaG5m1u/2kRCRx1MAjnT7eQqucdjw/ 06dkjgOlv2pZmEdbVIL2LfxLGtwmliVQLFK4gVzwwQ== X-Google-Smtp-Source: AOwi7QBiBAx40CjtnGCTF7IYC1UVZT7xPfE8glVtYdgQGaIOPzRXNZTmwh7BYHPoT3aLVC0El5d8IU3ejAAy2bGDD78= X-Received: by 10.202.217.215 with SMTP id q206mr13392371oig.188.1505399464291; Thu, 14 Sep 2017 07:31:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Thu, 14 Sep 2017 07:30:23 -0700 (PDT) In-Reply-To: References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.com> From: Eric Rescorla Date: Thu, 14 Sep 2017 07:30:23 -0700 Message-ID: To: Benoit Claise Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG , draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle , curdle Content-Type: multipart/alternative; boundary="001a113d57ba5083210559272093" Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 14:31:09 -0000 --001a113d57ba5083210559272093 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, and don't mark things as obsolete :) On Thu, Sep 14, 2017 at 7:29 AM, Eric Rescorla wrote: > Per today's discussion on the IESG Call, the resolution is: > > 1. Move 4757 to Historic > 2. Include a sentence saying that people still use these algorithms (both= , > actually) but we are moving things to Historic to tell you not to. > > OK? > -Ekr > > > > On Thu, Sep 14, 2017 at 6:46 AM, Benoit Claise wrote: > >> On 9/4/2017 3:47 PM, Mirja K=C3=BChlewind wrote: >> >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-curdle-des-des-des-die-die-die-04: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/stat >>> ement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-d >>> es-die-die-die/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is mainly a processing question, so probably more for the IESG to >>> discuss >>> than the authors: >>> >>> I understand the intention of obsoleting RFC4757 to declare that the >>> algorithms >>> described should not be used anymore, however, rfc4757 is an >>> informational >>> implementation description which is probably still deployed. Obsoleting >>> an >>> informational implementation description seems a bit weird. Just would >>> like to >>> double-check with the rest of the IESG if that action appropriate...? >>> >>> Also obsoleting and moving to historic is not the same thing. The >>> document says: >>> "This document recommends the reclassification of [RFC4757] as Historic= ." >>> One of the two actions (obsoleting or moving to historic) is enough. >>> While I >>> think moving to historic might actually be more appropriate than >>> obsoleting an >>> implementation description, >>> >> Historical makes sense. So does it mean that >> draft-ietf-curdle-des-des-des-die-die-die is used as "status-change" >> document in https://www.ietf.org/iesg/statement/designating-rfcs-as-hist >> oric.html? >> >>> it should only be moved to historic if this is not >>> used and deployed anymore. >>> >> Where does this condition come from? >> >> Regards, B. >> >>> Also moving to historic also requires a status >>> change action. >>> >>> >>> >>> >>> . >>> >>> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --001a113d57ba5083210559272093 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, and don't mark things as obsolete :)

On Thu, Sep 14, 2017 at 7= :29 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Per today's discussion on the IESG Call,= the resolution is:

1. Move=C2=A04757 to Historic
2. Include a sentence saying that people still use these algorithms (both= , actually) but we are moving things to Historic to tell you not to.=

OK?
-Ekr

=


On Thu, Sep 14, 2017 at 6:46 AM= , Benoit Claise <bclaise@cisco.com> wrote:
On 9/4/2017 3:47 PM, Mirja K=C3=BChlewind wrote:
Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-curdle-des-des-des-die-die-die/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is mainly a processing question, so probably more for the IESG to disc= uss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algori= thms
described should not be used anymore, however, rfc4757 is an informational<= br> implementation description which is probably still deployed. Obsoleting an<= br> informational implementation description seems a bit weird. Just would like= to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document = says:
"This document recommends the reclassification of [RFC4757] as Histori= c."
One of the two actions (obsoleting or moving to historic) is enough. While = I
think moving to historic might actually be more appropriate than obsoleting= an
implementation description,
Historical makes sense. So does it mean that draft-ietf-curdle-des-des-des-= die-die-die is used as "status-change" document in https://www.ietf.org/iesg/stateme= nt/designating-rfcs-as-historic.html?
it should only be moved to historic if this is not
used and deployed anymore.
 Where does this condition come from?

Regards, B.
Also moving to historic also requires a status
change action.




 .


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


--001a113d57ba5083210559272093-- From nobody Thu Sep 14 07:33: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 3FE1013302B; Thu, 14 Sep 2017 07:33:04 -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 AgIKda24IN_D; Thu, 14 Sep 2017 07:33:02 -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 A85AB13301B; Thu, 14 Sep 2017 07:33:01 -0700 (PDT) X-AuditID: c6180641-0dfff70000002d27-76-59ba4cb95454 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id ED.95.11559.9BC4AB95; Thu, 14 Sep 2017 11:32:41 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0352.000; Thu, 14 Sep 2017 10:33:00 -0400 From: Daniel Migault To: Eric Rescorla , Benoit Claise CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG , "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , curdle , curdle Thread-Topic: =?utf-8?B?W0N1cmRsZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUtMDQ6ICh3aXRo?= =?utf-8?Q?_DISCUSS)?= Thread-Index: AQHTJYRmXwnOJnarjE2o9EhtYVo3lqK0t8CAgAAL4QCAAABjgP//vYiQ Date: Thu, 14 Sep 2017 14:32:58 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0@eusaamb107.ericsson.se> References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.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.12] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyuXRPrO5On12RBut2a1gcfSxhMbNnA7PF 1oWzmC2edh1hsljx+hy7xYw/E5ktXlz/yOzA7jHl90ZWjyVLfjJ5tHxcyOox+XEbcwBLFJdN SmpOZllqkb5dAlfG0nctTAVX6isOTe9namCcU9PFyMkhIWAi8Wzec6YuRi4OIYGjjBI/9vxm BEkICSxnlGh+xgliswkYSbQd6mcHsUUEnCX+bV8N1sAs0MIk8XfXYhYQR1hgB6PE3qsvmEEc EYGdjBKrj91lgWhxk3gx6RwbiM0ioCrx+PE1MJtXwFdi1bQWFojdPUwSp6d2AM3l4OAUCJQ4 vT8LpIZRQEzi+6k1TCA2s4C4xK0n85kg7haQWLLnPDOELSrx8vE/VghbSWLO62vMEPX5Euta d7NA7BKUODnzCcsERpFZSEbNQlI2C0nZLKArmAU0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwB I/sqRo7S4oKc3HQjw02MwCg8JsHmuINxb6/nIUYBDkYlHt4mw12RQqyJZcWVuYcYJTiYlUR4 XScChXhTEiurUovy44tKc1KLDzFKc7AoifO+K78QISSQnliSmp2aWpBaBJNl4uCUamA0VYqa lqtVMbFE8IdWxzz+8xu/nrN5Ubr0RKrtpcPWk9ey2+3b5XNq+pPbObv9uZ4Fe7tKt0h95BcT //130oQWP/cZ2s+3HHpk/+Fdt8MpleQ3vQ5mHRwq2yLZLpQ8XzwnLJG56KPSc1vnybfOOt9v vfxLbnF2wjVu9opld/U7Pe6YeG8XOlGixFKckWioxVxUnAgAPDDwjL4CAAA= Archived-At: Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 14:33:04 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLiBUaGFua3MuDQpZb3VycywNCkRhbmllbA0KDQpGcm9tOiBFcmljIFJlc2Nv cmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxNCwg MjAxNyAxMDozMCBBTQ0KVG86IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPg0KQ2M6 IE1pcmphIEvDvGhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+OyBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZz47IGRyYWZ0LWlldGYtY3VyZGxlLWRlcy1kZXMtZGVzLWRpZS1kaWUtZGllQGlldGYu b3JnOyBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPjsgY3VyZGxl IDxjdXJkbGUtY2hhaXJzQGlldGYub3JnPjsgY3VyZGxlIDxjdXJkbGVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW0N1cmRsZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUtMDQ6ICh3aXRoIERJU0NVU1MpDQoNCk9o LCBhbmQgZG9uJ3QgbWFyayB0aGluZ3MgYXMgb2Jzb2xldGUgOikNCg0KT24gVGh1LCBTZXAgMTQs IDIwMTcgYXQgNzoyOSBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+PiB3cm90ZToNClBlciB0b2RheSdzIGRpc2N1c3Npb24gb24gdGhlIElFU0cgQ2Fs bCwgdGhlIHJlc29sdXRpb24gaXM6DQoNCjEuIE1vdmUgNDc1NyB0byBIaXN0b3JpYw0KMi4gSW5j bHVkZSBhIHNlbnRlbmNlIHNheWluZyB0aGF0IHBlb3BsZSBzdGlsbCB1c2UgdGhlc2UgYWxnb3Jp dGhtcyAoYm90aCwgYWN0dWFsbHkpIGJ1dCB3ZSBhcmUgbW92aW5nIHRoaW5ncyB0byBIaXN0b3Jp YyB0byB0ZWxsIHlvdSBub3QgdG8uDQoNCk9LPw0KLUVrcg0KDQoNCg0KT24gVGh1LCBTZXAgMTQs IDIwMTcgYXQgNjo0NiBBTSwgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRv OmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6DQpPbiA5LzQvMjAxNyAzOjQ3IFBNLCBNaXJqYSBL w7xobGV3aW5kIHdyb3RlOg0KTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtY3VyZGxlLWRlcy1kZXMtZGVzLWRp ZS1kaWUtZGllLTA0OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUvDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGlzIG1haW5seSBhIHByb2Nlc3Np bmcgcXVlc3Rpb24sIHNvIHByb2JhYmx5IG1vcmUgZm9yIHRoZSBJRVNHIHRvIGRpc2N1c3MNCnRo YW4gdGhlIGF1dGhvcnM6DQoNCkkgdW5kZXJzdGFuZCB0aGUgaW50ZW50aW9uIG9mIG9ic29sZXRp bmcgUkZDNDc1NyB0byBkZWNsYXJlIHRoYXQgdGhlIGFsZ29yaXRobXMNCmRlc2NyaWJlZCBzaG91 bGQgbm90IGJlIHVzZWQgYW55bW9yZSwgaG93ZXZlciwgcmZjNDc1NyBpcyBhbiBpbmZvcm1hdGlv bmFsDQppbXBsZW1lbnRhdGlvbiBkZXNjcmlwdGlvbiB3aGljaCBpcyBwcm9iYWJseSBzdGlsbCBk ZXBsb3llZC4gT2Jzb2xldGluZyBhbg0KaW5mb3JtYXRpb25hbCBpbXBsZW1lbnRhdGlvbiBkZXNj cmlwdGlvbiBzZWVtcyBhIGJpdCB3ZWlyZC4gSnVzdCB3b3VsZCBsaWtlIHRvDQpkb3VibGUtY2hl Y2sgd2l0aCB0aGUgcmVzdCBvZiB0aGUgSUVTRyBpZiB0aGF0IGFjdGlvbiBhcHByb3ByaWF0ZS4u Lj8NCg0KQWxzbyBvYnNvbGV0aW5nIGFuZCBtb3ZpbmcgdG8gaGlzdG9yaWMgaXMgbm90IHRoZSBz YW1lIHRoaW5nLiBUaGUgZG9jdW1lbnQgc2F5czoNCiJUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMg dGhlIHJlY2xhc3NpZmljYXRpb24gb2YgW1JGQzQ3NTddIGFzIEhpc3RvcmljLiINCk9uZSBvZiB0 aGUgdHdvIGFjdGlvbnMgKG9ic29sZXRpbmcgb3IgbW92aW5nIHRvIGhpc3RvcmljKSBpcyBlbm91 Z2guIFdoaWxlIEkNCnRoaW5rIG1vdmluZyB0byBoaXN0b3JpYyBtaWdodCBhY3R1YWxseSBiZSBt b3JlIGFwcHJvcHJpYXRlIHRoYW4gb2Jzb2xldGluZyBhbg0KaW1wbGVtZW50YXRpb24gZGVzY3Jp cHRpb24sDQpIaXN0b3JpY2FsIG1ha2VzIHNlbnNlLiBTbyBkb2VzIGl0IG1lYW4gdGhhdCBkcmFm dC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZSBpcyB1c2VkIGFzICJzdGF0dXMt Y2hhbmdlIiBkb2N1bWVudCBpbiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k ZXNpZ25hdGluZy1yZmNzLWFzLWhpc3RvcmljLmh0bWw/DQppdCBzaG91bGQgb25seSBiZSBtb3Zl ZCB0byBoaXN0b3JpYyBpZiB0aGlzIGlzIG5vdA0KdXNlZCBhbmQgZGVwbG95ZWQgYW55bW9yZS4N CldoZXJlIGRvZXMgdGhpcyBjb25kaXRpb24gY29tZSBmcm9tPw0KDQpSZWdhcmRzLCBCLg0KQWxz byBtb3ZpbmcgdG8gaGlzdG9yaWMgYWxzbyByZXF1aXJlcyBhIHN0YXR1cw0KY2hhbmdlIGFjdGlv bi4NCg0KDQoNCg0KLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQ3VyZGxlIG1haWxpbmcgbGlzdA0KQ3VyZGxlQGlldGYub3JnPG1haWx0bzpDdXJk bGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRs ZQ0KDQoNCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0eusaamb107erics_ 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 YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldvcmtzIGZvciBtZS4gVGhhbmtzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91cnMsDQo8 YnI+DQpEYW5pZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIFNlcHRlbWJlciAxNCwgMjAxNyAxMDozMCBBTTxicj4NCjxiPlRvOjwv Yj4gQmVub2l0IENsYWlzZSAmbHQ7YmNsYWlzZUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBNaXJqYSBLw7xobGV3aW5kICZsdDtpZXRmQGt1ZWhsZXdpbmQubmV0Jmd0OzsgVGhlIElFU0cg Jmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUt ZGllLWRpZUBpZXRmLm9yZzsgRGFuaWVsIE1pZ2F1bHQgJmx0O2RhbmllbC5taWdhdWx0QGVyaWNz c29uLmNvbSZndDs7IGN1cmRsZSAmbHQ7Y3VyZGxlLWNoYWlyc0BpZXRmLm9yZyZndDs7IGN1cmRs ZSAmbHQ7Y3VyZGxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0N1cmRs ZV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jdXJkbGUtZGVzLWRl cy1kZXMtZGllLWRpZS1kaWUtMDQ6ICh3aXRoIERJU0NVU1MpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T2gsIGFuZCBkb24ndCBtYXJrIHRoaW5ncyBhcyBvYnNvbGV0ZSA6 KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBT ZXAgMTQsIDIwMTcgYXQgNzoyOSBBTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXIgdG9kYXkncyBkaXNjdXNzaW9uIG9uIHRoZSBJRVNHIENhbGwsIHRoZSByZXNvbHV0aW9u IGlzOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gTW92 ZSZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjQ3NTcgdG8gSGlzdG9yaWM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4yLiBJbmNsdWRlIGEgc2VudGVuY2Ugc2F5aW5n IHRoYXQgcGVvcGxlIHN0aWxsIHVzZSB0aGVzZSBhbGdvcml0aG1zIChib3RoLCBhY3R1YWxseSkg YnV0IHdlIGFyZSBtb3ZpbmcgdGhpbmdzIHRvIEhpc3RvcmljIHRvIHRlbGwgeW91IG5vdCB0by48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPk9LPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPi1Fa3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgU2VwIDE0LCAy MDE3IGF0IDY6NDYgQU0sIEJlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNl QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiA5LzQvMjAxNyAzOjQ3IFBNLCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pcmphIEvD vGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJy Pg0KZHJhZnQtaWV0Zi1jdXJkbGUtZGVzLWRlcy1kZXMtZGllLWRpZS1kaWUtMDQ6IERpc2N1c3M8 YnI+DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCmludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4NCjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0 byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnI+DQpmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4N Cjxicj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZTo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWN1cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZS8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWN1 cmRsZS1kZXMtZGVzLWRlcy1kaWUtZGllLWRpZS88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCkRJU0NVU1M6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4N ClRoaXMgaXMgbWFpbmx5IGEgcHJvY2Vzc2luZyBxdWVzdGlvbiwgc28gcHJvYmFibHkgbW9yZSBm b3IgdGhlIElFU0cgdG8gZGlzY3Vzczxicj4NCnRoYW4gdGhlIGF1dGhvcnM6PGJyPg0KPGJyPg0K SSB1bmRlcnN0YW5kIHRoZSBpbnRlbnRpb24gb2Ygb2Jzb2xldGluZyBSRkM0NzU3IHRvIGRlY2xh cmUgdGhhdCB0aGUgYWxnb3JpdGhtczxicj4NCmRlc2NyaWJlZCBzaG91bGQgbm90IGJlIHVzZWQg YW55bW9yZSwgaG93ZXZlciwgcmZjNDc1NyBpcyBhbiBpbmZvcm1hdGlvbmFsPGJyPg0KaW1wbGVt ZW50YXRpb24gZGVzY3JpcHRpb24gd2hpY2ggaXMgcHJvYmFibHkgc3RpbGwgZGVwbG95ZWQuIE9i c29sZXRpbmcgYW48YnI+DQppbmZvcm1hdGlvbmFsIGltcGxlbWVudGF0aW9uIGRlc2NyaXB0aW9u IHNlZW1zIGEgYml0IHdlaXJkLiBKdXN0IHdvdWxkIGxpa2UgdG88YnI+DQpkb3VibGUtY2hlY2sg d2l0aCB0aGUgcmVzdCBvZiB0aGUgSUVTRyBpZiB0aGF0IGFjdGlvbiBhcHByb3ByaWF0ZS4uLj88 YnI+DQo8YnI+DQpBbHNvIG9ic29sZXRpbmcgYW5kIG1vdmluZyB0byBoaXN0b3JpYyBpcyBub3Qg dGhlIHNhbWUgdGhpbmcuIFRoZSBkb2N1bWVudCBzYXlzOjxicj4NCiZxdW90O1RoaXMgZG9jdW1l bnQgcmVjb21tZW5kcyB0aGUgcmVjbGFzc2lmaWNhdGlvbiBvZiBbUkZDNDc1N10gYXMgSGlzdG9y aWMuJnF1b3Q7PGJyPg0KT25lIG9mIHRoZSB0d28gYWN0aW9ucyAob2Jzb2xldGluZyBvciBtb3Zp bmcgdG8gaGlzdG9yaWMpIGlzIGVub3VnaC4gV2hpbGUgSTxicj4NCnRoaW5rIG1vdmluZyB0byBo aXN0b3JpYyBtaWdodCBhY3R1YWxseSBiZSBtb3JlIGFwcHJvcHJpYXRlIHRoYW4gb2Jzb2xldGlu ZyBhbjxicj4NCmltcGxlbWVudGF0aW9uIGRlc2NyaXB0aW9uLDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpc3Rvcmlj YWwgbWFrZXMgc2Vuc2UuIFNvIGRvZXMgaXQgbWVhbiB0aGF0IGRyYWZ0LWlldGYtY3VyZGxlLWRl cy1kZXMtZGVzLWRpZS1kaWUtZGllIGlzIHVzZWQgYXMgJnF1b3Q7c3RhdHVzLWNoYW5nZSZxdW90 OyBkb2N1bWVudCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGVzaWduYXRpbmctcmZjcy1hcy1oaXN0b3JpYy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kZXNpZ25hdGluZy1yZmNzLWFzLWhp c3RvcmljLmh0bWw8L2E+PzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPml0IHNob3VsZCBvbmx5IGJlIG1vdmVkIHRvIGhpc3RvcmljIGlmIHRoaXMgaXMg bm90PGJyPg0KdXNlZCBhbmQgZGVwbG95ZWQgYW55bW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXJlIGRvZXMgdGhpcyBjb25kaXRpb24g Y29tZSBmcm9tPzxicj4NCjxicj4NClJlZ2FyZHMsIEIuPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5B bHNvIG1vdmluZyB0byBoaXN0b3JpYyBhbHNvIHJlcXVpcmVzIGEgc3RhdHVzPGJyPg0KY2hhbmdl IGFjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQouPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ3VyZGxl IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDdXJkbGVAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5DdXJkbGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0eusaamb107erics_-- From nobody Thu Sep 14 07:55:23 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A313235C; Thu, 14 Sep 2017 07:55:15 -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, 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 uERjRzSbMA2a; Thu, 14 Sep 2017 07:55:13 -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 85002132335; Thu, 14 Sep 2017 07:55:12 -0700 (PDT) X-AuditID: 1209190d-023ff70000007bb7-48-59ba984f5d10 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 05.E2.31671.F489AB95; Thu, 14 Sep 2017 10:55:11 -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 v8EEt9MX008621; Thu, 14 Sep 2017 10:55:09 -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 v8EEt3TU020509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Sep 2017 10:55:06 -0400 Date: Thu, 14 Sep 2017 09:55:04 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: Eric Rescorla , Benoit Claise , Mirja =?iso-8859-1?Q?K=FChlewind?= , The IESG , "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" , curdle , curdle Message-ID: <20170914145503.GQ96685@kduck.kaduk.org> References: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com> <9433317a-bc70-2093-c83b-170c31dd88c5@cisco.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CE11A0@eusaamb107.ericsson.se> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUixCmqrOs/Y1ekwbrVohZHH0tYzOzZwGyx deEsZosp0/ewWTztOsJkseL1OXaLGX8mMlu8uP6R2YHDY8rvjawev75eZfNYsuQnk0fLx4Ws HpMftzEHsEZx2aSk5mSWpRbp2yVwZdxZV1NwWari2LQ7TA2M30S7GDk5JARMJDYuusDYxcjF ISSwmEni/IP/UM5GRoktS58xQThXmSRef57ECNLCIqAqcef9BGYQm01ARaKh+zKYLSJgIPFy wk42kAZmgYdMEle+t4ONEhZYwyixa8M1dpAqXqCFU3d/ZIcYe4FJ4kvzdEaIhKDEyZlPWEBs ZgEdiZ1b7wCN4gCypSWW/+OACMtLNG+dDbaNU8BP4tj1p2CtogLKEvP2rWKbwCg4C8mkWUgm zUKYNAvJpAWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCY0aSdwfjv7te hxgFOBiVeHgFJuyKFGJNLCuuzD3EKMnBpCTKu1d3Z6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYl EV7XiUDlvCmJlVWpRfkwKWkOFiVx3m1BQCmB9MSS1OzU1ILUIpisDAeHkgQv63SgrGBRanpq RVpmTglCmomDE2Q4D9Dw79NAhhcXJOYWZ6ZD5E8xKkqJ834ESQiAJDJK8+B6QSlNInt/zStG caBXhHlXgqzgAaZDuO5XQIOZgAafOb0DZHBJIkJKqoHxya9mo6edrbl7rzgu91d9E1N/6Xmt 49m3su3nRdpUHFzWdXNoBtzz5dn/JDjhgSpLtUXG7+sX7k+9UNKt9+2XglPGEdvH1dZe/6ys uJfbHQlic2R3emzIIL7skqDXostrmJICkhLmZrJOStpd1u2lt/yE27nk7x2Kmh9eSDkIzHE5 P/t6X5QSS3FGoqEWc1FxIgDlz77rRAMAAA== Archived-At: Subject: Re: [Curdle] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-i?= =?iso-8859-1?q?etf-curdle-des-des-des-die-die-die-04=3A_=28with_DISCUSS?= =?iso-8859-1?q?=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 14:55:16 -0000 On Thu, Sep 14, 2017 at 02:32:58PM +0000, Daniel Migault wrote: > Works for me. Thanks. > Yours, > Daniel > > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Thursday, September 14, 2017 10:30 AM > To: Benoit Claise > Cc: Mirja Kühlewind ; The IESG ; draft-ietf-curdle-des-des-des-die-die-die@ietf.org; Daniel Migault ; curdle ; curdle > Subject: Re: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS) > > Oh, and don't mark things as obsolete :) > > On Thu, Sep 14, 2017 at 7:29 AM, Eric Rescorla > wrote: > Per today's discussion on the IESG Call, the resolution is: > > 1. Move 4757 to Historic > 2. Include a sentence saying that people still use these algorithms (both, actually) but we are moving things to Historic to tell you not to. > I'm currently looking at (in addition to the other changes prompted by IESG evaluation): diff --git a/draft-ietf-curdle-des-des-des-die-die-die.xml b/draft-ietf-curdle-des-des-des-die-die-die.xml index 9db9438..0a853ae 100644 --- a/draft-ietf-curdle-des-des-des-die-die-die.xml +++ b/draft-ietf-curdle-des-des-des-die-die-die.xml @@ -10,7 +10,7 @@ ]> - + Deprecate 3DES and RC4 in Kerberos @@ -30,7 +30,7 @@ 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 + to Historic 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. @@ -41,7 +41,7 @@ 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 + to Historic 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. @@ -61,6 +61,9 @@ are in use with no formal specification, in particular des3-cbc-md5 and des3-cbc-sha1. These unspecified encryption types are also deprecated by this document. + Though the RC4 and 3DES encryption types are still in use in + some deployments, the above status changes are made to indicate + that these encryption types should no longer be used.
The following encryption types are deprecated. The numbers %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Should I go ahead and upload with that? Thanks, Ben From nobody Thu Sep 14 10:16: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 E923313218F; Thu, 14 Sep 2017 10:16:40 -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 9-RKbvzfFaw4; Thu, 14 Sep 2017 10:16:39 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 03E0C126BF0; Thu, 14 Sep 2017 10:16:39 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id q132so4340lfe.5; Thu, 14 Sep 2017 10:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ia+qMt+eG3mRlRtLs1b1YVEz6qH0hUTDoEb1dKhGNm4=; b=poh6eI0AeYG/GVsb+Kz7lWJn7OEi80Sb6KDewAxSfRxnmOxXgfaj4gKQ+d2tq6fxaj 225razgbt9EeJVtcrNC3CbOa2s5NuM2D7hu7f9DjPy4T9GFRYEA36Uv529xO6z0Joo1/ PIrKYaU1oUy4StA2OrzzyrbA3pgYZrqgGzcFwkRJvK2oLNu1bCo2bx5bqi7QSZz//52I 6E3H/F2e51gMDtRcAVUwIKlzmSbQjedDoEOQtz7G2RPiEyg0xgKFLVdrrez/oLtCC/H6 BYUHuV7MUc3+/JR9nvx2n/XoozUrcz45EDbhA/ZU2TahdM1Dycf+sARkNqfOi8U2WbJC Os9Q== 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=ia+qMt+eG3mRlRtLs1b1YVEz6qH0hUTDoEb1dKhGNm4=; b=X07/F7VxQJh9fHtvKyt3zaAJjGRTUKT9nOfTZHjrxxUDQPe+3KXx1d/TupB+pCgvmx oQ7xS95vhf047iy/twq1jbw1fHFHFpwlg4/hkLLyCsvIfF+WZBuDnllJpSgLUtNGWk99 RA45JeJoYqtI+GIK9zuly33DlAYCGjQ47AsNC50r7AbXznRq5G6kWf4sMyGr5g3+AlYL wdaUKtWZ2kA89u9ghq3GbyOjHgp6S4ODJNna8t3fddX7jnCtoEt2Nj8XQe24dVrxaVDD GZJawWI5J5mreL+oCF8AistxEaj4LqBa1BhCQUxvCTIa1KjrRmq6OS8kSm8JLQWTvbgW TpSw== X-Gm-Message-State: AHPjjUgFsqm5KpAiQfesXyme+Had3tCq+Kt4Cb4HLNC+iJZHMwfrIf90 5yVDM5N9vEQSLWCr2bruwYaZ66rML9zfI04c3kU= X-Google-Smtp-Source: AOwi7QBatX2e1oilu6PpJLWngtphJyN9FZIWk9MJLF9NBYsT7U7R+5ffcs5eqrpUsA8N9hdZT4uwWrrmFMOKX0wwcNc= X-Received: by 10.25.0.144 with SMTP id 138mr9290451lfa.64.1505409397354; Thu, 14 Sep 2017 10:16:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Thu, 14 Sep 2017 10:16:36 -0700 (PDT) In-Reply-To: <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> From: denis bider Date: Thu, 14 Sep 2017 11:16:36 -0600 Message-ID: To: Adam Roach Cc: Eric Rescorla , Daniel Migault , Alexey Melnikov , curdle-chairs , curdle , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="001a113c9e0c5ef6f60559297094" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 17:16:41 -0000 --001a113c9e0c5ef6f60559297094 Content-Type: text/plain; charset="UTF-8" But seriously, the spec defines the encoding. There needs to be no guessing. The definition is right there. The example further fool-proofs so there's no excuse for anyone to misunderstand. Nested strings in SSH are not weird. They are used ubiquitously. For example, in public key authentication, the public key is encoded as a string. This string itself contains other strings which are part of the public key format. This is not unusual. Anyone who works with SSH would be familiar with this. On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach wrote: > On 9/14/17 08:08, denis bider wrote: > >> Submitted. :-) >> > > Thanks. This newest version includes an example, but no further > explanation of the encoding. Normative examples that implementors have to > reverse engineer are generally bad for interoperability, since implementors > have to guess at the handling for corner cases. Could you please add text > that describes the encoding itself? It doesn't need to be overly complex, > but it does need to be explained. > > /a > --001a113c9e0c5ef6f60559297094 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But seriously, the spec defines the encoding. There needs = to be no guessing. The definition is right there. The example further fool-= proofs so there's no excuse for anyone to misunderstand.

=
Nested strings in SSH are not weird. They are used ubiquitously. = For example, in public key authentication, the public key is encoded as a s= tring. This string itself contains other strings which are part of the publ= ic key format. This is not unusual. Anyone who works with SSH would be fami= liar with this.

On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <adam@nostrum.= com> wrote:
On 9/14/17 08:0= 8, denis bider wrote:
Submitted. :-)

Thanks. This newest version includes an example, but no further explanation= of the encoding. Normative examples that implementors have to reverse engi= neer are generally bad for interoperability, since implementors have to gue= ss at the handling for corner cases. Could you please add text that describ= es the encoding itself? It doesn't need to be overly complex, but it do= es need to be explained.

/a

--001a113c9e0c5ef6f60559297094-- From nobody Thu Sep 14 10:24: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 B76C91326FE; Thu, 14 Sep 2017 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMokTT5crLMI; Thu, 14 Sep 2017 10:24:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2E673126BF0; Thu, 14 Sep 2017 10:24:42 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8EHOXxV083951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 12:24:33 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: denis bider Cc: Eric Rescorla , Daniel Migault , Alexey Melnikov , curdle-chairs , curdle , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> From: Adam Roach Message-ID: <5e1427b5-671f-4bda-5f63-544172849252@nostrum.com> Date: Thu, 14 Sep 2017 12:24:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2C8FECC8C28ADE3ED3D47718" Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 17:24:44 -0000 This is a multi-part message in MIME format. --------------2C8FECC8C28ADE3ED3D47718 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ah, okay. I thought I'd asked earlier for an example of nested strings, and was interpreting your lack of response as a lack of such thing. If this kind of nesting is commonplace for the base protocol, then I'm okay with the current formulation. My concern was that this looked like something novel, but with only a loosely implied encoding. I'll clear my discuss. Thanks for the explanation. /a On 9/14/17 12:16, denis bider wrote: > But seriously, the spec defines the encoding. There needs to be no > guessing. The definition is right there. The example further > fool-proofs so there's no excuse for anyone to misunderstand. > > Nested strings in SSH are not weird. They are used ubiquitously. For > example, in public key authentication, the public key is encoded as a > string. This string itself contains other strings which are part of > the public key format. This is not unusual. Anyone who works with SSH > would be familiar with this. > > On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach > wrote: > > On 9/14/17 08:08, denis bider wrote: > > Submitted. :-) > > > Thanks. This newest version includes an example, but no further > explanation of the encoding. Normative examples that implementors > have to reverse engineer are generally bad for interoperability, > since implementors have to guess at the handling for corner cases. > Could you please add text that describes the encoding itself? It > doesn't need to be overly complex, but it does need to be explained. > > /a > > --------------2C8FECC8C28ADE3ED3D47718 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Ah, okay. I thought I'd asked earlier for an example of nested strings, and was interpreting your lack of response as a lack of such thing. If this kind of nesting is commonplace for the base protocol, then I'm okay with the current formulation. My concern was that this looked like something novel, but with only a loosely implied encoding.

I'll clear my discuss. Thanks for the explanation.

/a

On 9/14/17 12:16, denis bider wrote:
But seriously, the spec defines the encoding. There needs to be no guessing. The definition is right there. The example further fool-proofs so there's no excuse for anyone to misunderstand.

Nested strings in SSH are not weird. They are used ubiquitously. For example, in public key authentication, the public key is encoded as a string. This string itself contains other strings which are part of the public key format. This is not unusual. Anyone who works with SSH would be familiar with this.

On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <adam@nostrum.com> wrote:
On 9/14/17 08:08, denis bider wrote:
Submitted. :-)

Thanks. This newest version includes an example, but no further explanation of the encoding. Normative examples that implementors have to reverse engineer are generally bad for interoperability, since implementors have to guess at the handling for corner cases. Could you please add text that describes the encoding itself? It doesn't need to be overly complex, but it does need to be explained.

/a


--------------2C8FECC8C28ADE3ED3D47718-- From nobody Thu Sep 14 10:30:05 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2006133025; Thu, 14 Sep 2017 10:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150541019862.12598.17460940848528860343@ietfa.amsl.com> Date: Thu, 14 Sep 2017 10:29:58 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-14.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, 14 Sep 2017 17:29:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-14.txt Pages : 13 Date : 2017-09-14 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-14 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 Sep 14 10:31: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 55223133025; Thu, 14 Sep 2017 10:31:26 -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 Qb0mjNY3G6JZ; Thu, 14 Sep 2017 10:31:24 -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 2493C126D0C; Thu, 14 Sep 2017 10:31:24 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id k23so28430lfi.11; Thu, 14 Sep 2017 10:31:24 -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=dD3LBA9kxXaiIivTPuB0PnXsAWzGj8/EkJbxJcIapLw=; b=Rj+G8DPqtZO1L+XRPmBrRvsFq4sueYqu7WRtMlAXxV0LoTmyAqg16RDkOkDmbRyTpN 4b4OKcgcxYqUbSBjXYAOefG3Yt1yLRXt19bCow/1jfyMPUTAGrXo4rH9TBMAuFWxD5pn W9ji3IYprVK7fJpEhnTK4eei7F21mN38Cta/hEhQ8nPGOY32zs4PL2mnWZd0VzspCCVr PyuKtdwsPAzPG65opgF4CmJFF95sIGdWvKgQTi+tiJ8VhSk5NK3uVMbNGWOD4uCa8ovJ i/1T5fodmQzKSNSkDjgCukOOgvSzQ9HkrBEJJaUJJNIWbBstPw/YF0IEm++e7s5gnS8X R1ew== 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=dD3LBA9kxXaiIivTPuB0PnXsAWzGj8/EkJbxJcIapLw=; b=VJ5ZljkIWMZrUZl37kOPcVDsR118NGXVO2RUsl5NzMSI8l0Q4UD5DG9/ELQLBXvKLL l4jHSy2T5z2tCaM30Y98AqEfcl1TaP0VRHVTxS8KNrj8e/2EzVrSAvsftP72kZGabHzx MEt7rB10Ryu1jqOMLICmLraLwxBXcA+DsX89bJLT2Nz/gj53CX6sc31TXVZVO5a2EDNO Oyt/XsVv5+AWTy2v/ZHg+/GYfdIFd+1c1OhKKd7RuKV2wmdeK+JUyizHt4efTbLoO+g0 ZkD80wPfq9XztCUC4EnUejzrLnAU6IRpAm6yddvDZizpXVR1qCPTP2BsIofy1RBbVkyk J8Iw== X-Gm-Message-State: AHPjjUhGi7C8uVlRqmmPFAlHcZre+GlmUhMk8e33YLds9UuKcl3QvduF d1dRUiX9vzvzDC/xpeGBWRzDxr7egpN5PEmpz3s= X-Google-Smtp-Source: ADKCNb7OXsoGKksGUz0UPQ3NVdfy99Ugc2bNNpxhGbyiIAjbKsEIoKU0382Faxx64QbJaKwyV3JF4VCihCVzHvAKZLw= X-Received: by 10.46.20.27 with SMTP id u27mr7026009ljd.39.1505410282324; Thu, 14 Sep 2017 10:31:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Thu, 14 Sep 2017 10:31:21 -0700 (PDT) In-Reply-To: <5e1427b5-671f-4bda-5f63-544172849252@nostrum.com> References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> <5e1427b5-671f-4bda-5f63-544172849252@nostrum.com> From: denis bider Date: Thu, 14 Sep 2017 11:31:21 -0600 Message-ID: To: Adam Roach Cc: Eric Rescorla , Daniel Migault , Alexey Melnikov , curdle-chairs , curdle , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org Content-Type: multipart/alternative; boundary="f403045fbb901e8662055929a591" Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 17:31:26 -0000 --f403045fbb901e8662055929a591 Content-Type: text/plain; charset="UTF-8" Just to be sure, I've uploaded a new version that does contain the extra explanation as well. Let me know if it's clearer. On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach wrote: > Ah, okay. I thought I'd asked earlier for an example of nested strings, > and was interpreting your lack of response as a lack of such thing. If this > kind of nesting is commonplace for the base protocol, then I'm okay with > the current formulation. My concern was that this looked like something > novel, but with only a loosely implied encoding. > > I'll clear my discuss. Thanks for the explanation. > > /a > > > On 9/14/17 12:16, denis bider wrote: > > But seriously, the spec defines the encoding. There needs to be no > guessing. The definition is right there. The example further fool-proofs so > there's no excuse for anyone to misunderstand. > > Nested strings in SSH are not weird. They are used ubiquitously. For > example, in public key authentication, the public key is encoded as a > string. This string itself contains other strings which are part of the > public key format. This is not unusual. Anyone who works with SSH would be > familiar with this. > > On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach wrote: > >> On 9/14/17 08:08, denis bider wrote: >> >>> Submitted. :-) >>> >> >> Thanks. This newest version includes an example, but no further >> explanation of the encoding. Normative examples that implementors have to >> reverse engineer are generally bad for interoperability, since implementors >> have to guess at the handling for corner cases. Could you please add text >> that describes the encoding itself? It doesn't need to be overly complex, >> but it does need to be explained. >> >> /a >> > > > --f403045fbb901e8662055929a591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to be sure, I've uploaded a new version that does= contain the extra explanation as well. Let me know if it's clearer.

On Thu, Sep 14= , 2017 at 11:24 AM, Adam Roach <adam@nostrum.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20
Ah, okay. I thought= I'd asked earlier for an example of nested strings, and was interpreting your lack of response as a lack of such thing. If this kind of nesting is commonplace for the base protocol, then I'm okay with the current formulation. My concern was that this looked like something novel, but with only a loosely implied encoding.

I'll clear my discuss. Thanks for the explanation.

/a


On 9/14/17 12:16, denis bider wrote:
But seriously, the spec defines the encoding. There needs to be no guessing. The definition is right there. The example further fool-proofs so there's no excuse for anyone to misunderstand.

Nested strings in SSH are not weird. They are used ubiquitously. For example, in public key authentication, the public key is encoded as a string. This string itself contains other strings which are part of the public key format. This is not unusual. Anyone who works with SSH would be familiar with this.

On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <adam@nostrum.com> wrote:
On 9/14/17 08:08, denis bider wrote:
Submitted. :-)

Thanks. This newest version includes an example, but no further explanation of the encoding. Normative examples that implementors have to reverse engineer are generally bad for interoperability, since implementors have to guess at the handling for corner cases. Could you please add text that describes the encoding itself? It doesn't need to be overly complex, but it does need to be explained.

/a



--f403045fbb901e8662055929a591-- From nobody Thu Sep 14 10:47: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 9A0AA132710; Thu, 14 Sep 2017 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8nTSCTkHbjP; Thu, 14 Sep 2017 10:46:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0DB3B1326FE; Thu, 14 Sep 2017 10:46:57 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8EHkpqX087913 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 12:46:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: denis bider Cc: Eric Rescorla , Daniel Migault , Alexey Melnikov , curdle-chairs , curdle , The IESG , draft-ietf-curdle-ssh-ext-info@ietf.org References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> <5e1427b5-671f-4bda-5f63-544172849252@nostrum.com> From: Adam Roach Message-ID: <5f0be446-7566-4c9c-4041-23c25f879374@nostrum.com> Date: Thu, 14 Sep 2017 12:46:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BD6E2BFEAE5C2028BC458151" Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 17:47:00 -0000 This is a multi-part message in MIME format. --------------BD6E2BFEAE5C2028BC458151 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks! The changes look good. /a On 9/14/17 12:31, denis bider wrote: > Just to be sure, I've uploaded a new version that does contain the > extra explanation as well. Let me know if it's clearer. > > On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach > wrote: > > Ah, okay. I thought I'd asked earlier for an example of nested > strings, and was interpreting your lack of response as a lack of > such thing. If this kind of nesting is commonplace for the base > protocol, then I'm okay with the current formulation. My concern > was that this looked like something novel, but with only a loosely > implied encoding. > > I'll clear my discuss. Thanks for the explanation. > > /a > > > On 9/14/17 12:16, denis bider wrote: >> But seriously, the spec defines the encoding. There needs to be >> no guessing. The definition is right there. The example further >> fool-proofs so there's no excuse for anyone to misunderstand. >> >> Nested strings in SSH are not weird. They are used ubiquitously. >> For example, in public key authentication, the public key is >> encoded as a string. This string itself contains other strings >> which are part of the public key format. This is not unusual. >> Anyone who works with SSH would be familiar with this. >> >> On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach > > wrote: >> >> On 9/14/17 08:08, denis bider wrote: >> >> Submitted. :-) >> >> >> Thanks. This newest version includes an example, but no >> further explanation of the encoding. Normative examples that >> implementors have to reverse engineer are generally bad for >> interoperability, since implementors have to guess at the >> handling for corner cases. Could you please add text that >> describes the encoding itself? It doesn't need to be overly >> complex, but it does need to be explained. >> >> /a >> >> > > --------------BD6E2BFEAE5C2028BC458151 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thanks! The changes look good.

/a

On 9/14/17 12:31, denis bider wrote:
Just to be sure, I've uploaded a new version that does contain the extra explanation as well. Let me know if it's clearer.

On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach <adam@nostrum.com> wrote:
Ah, okay. I thought I'd asked earlier for an example of nested strings, and was interpreting your lack of response as a lack of such thing. If this kind of nesting is commonplace for the base protocol, then I'm okay with the current formulation. My concern was that this looked like something novel, but with only a loosely implied encoding.

I'll clear my discuss. Thanks for the explanation.

/a


On 9/14/17 12:16, denis bider wrote:
But seriously, the spec defines the encoding. There needs to be no guessing. The definition is right there. The example further fool-proofs so there's no excuse for anyone to misunderstand.

Nested strings in SSH are not weird. They are used ubiquitously. For example, in public key authentication, the public key is encoded as a string. This string itself contains other strings which are part of the public key format. This is not unusual. Anyone who works with SSH would be familiar with this.

On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <adam@nostrum.com> wrote:
On 9/14/17 08:08, denis bider wrote:
Submitted. :-)

Thanks. This newest version includes an example, but no further explanation of the encoding. Normative examples that implementors have to reverse engineer are generally bad for interoperability, since implementors have to guess at the handling for corner cases. Could you please add text that describes the encoding itself? It doesn't need to be overly complex, but it does need to be explained.

/a




--------------BD6E2BFEAE5C2028BC458151-- From nobody Thu Sep 14 11:27: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 4BE06132397; Thu, 14 Sep 2017 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 pHvR7Jp6VGNV; Thu, 14 Sep 2017 11:27:05 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0111.outbound.protection.outlook.com [104.47.37.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36E51321DF; Thu, 14 Sep 2017 11:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FW4pf4DTHnV/kuMYmUosFq8o+lSi4VOnX7GaobtbFiQ=; b=gIO5HViyobQTJNJfURfWcwXzJQWB4EW0z4Swh0z04ptMGZMyj3/Y1ylmIm2A+Uhc2FmYDimk+LoOGWbfqyV5rwlo9x2Y5zFjdM+5bgbvgc4myC1vSlXb67QP+othN0fAPsquZTXzyPpkygo1GXMhUchds2ubgElzAYz9LReATZA= Received: from BY2PR05CA030.namprd05.prod.outlook.com (10.141.250.20) by BLUPR0501MB2065.namprd05.prod.outlook.com (10.164.23.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 18:27:03 +0000 Received: from CO1NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::201) by BY2PR05CA030.outlook.office365.com (2a01:111:e400:2c5f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.77.5 via Frontend Transport; Thu, 14 Sep 2017 18:27:02 +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 CO1NAM05FT038.mail.protection.outlook.com (10.152.96.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Thu, 14 Sep 2017 18:27:02 +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, 14 Sep 2017 11:26: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 v8EIQln3030990; Thu, 14 Sep 2017 11:26: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 974191144E; Thu, 14 Sep 2017 11:26:46 -0700 (PDT) To: Alexey Melnikov , The IESG , , Daniel Migault , , In-Reply-To: <3253.1505310397@eng-mail01.juniper.net> References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> <3253.1505310397@eng-mail01.juniper.net> Comments: In-reply-to: "Mark D. Baushke" message dated "Wed, 13 Sep 2017 06:46:37 -0700." From: "Mark D. Baushke" Date: Thu, 14 Sep 2017 11:26:46 -0700 Message-ID: <39647.1505413606@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)(346002)(39860400002)(376002)(2980300002)(199003)(189002)(69596002)(50986999)(106466001)(105596002)(76506005)(54356999)(76176999)(68736007)(6266002)(8936002)(81166006)(81156014)(8676002)(53416004)(53936002)(117636001)(230783001)(6246003)(50466002)(4743002)(48376002)(97736004)(2950100002)(97876018)(189998001)(2906002)(5003940100001)(2810700001)(6392003)(7846003)(356003)(229853002)(966005)(2201001)(316002)(7696004)(86362001)(47776003)(55016002)(305945005)(77096006)(16586007)(478600001)(5660300001)(6306002)(7126002)(8666007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2065; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT038; 1:EoadDWKD342Ve66LerUdJAN74Fj1uaH1p/B5h+l8SL8KDnPeHyq4oDdY3uy7F7mO4wc2mjlifh4JiFa3UcLTUaWk4eW+4s5dcyYR7HBhEOxyZJyjARZrYD7aFh4iNS66 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 83979c39-6e98-4110-da4e-08d4fb9e31b8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB2065; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 3:kJLrJwpem83PBPrEBwyOf5Wqv4546NMQHjpuP62cHCaZb/yMdBReT+tzw78yRiUMRx5AflncXLzrTlSf632gpNtNnPLMHQjbKo7PcEpfbCsO6m3B2nAV/3JlDstgbR1l0YZB8e9OUvljsmmUyluhV4fUr1V7qogDOA4J+ctioTQI871C9iZNfZJ1UVJsun4902/Qrley0YjZ5P6ZJGpBn2iePcvXriIEpygGyXHEI4MuCCcqNaTpAefLoxRsT+cS+KPOqQ/5fiQfvAY13Jx74cOp35iblJhSsSg5RQHs8AtIsi+NaDTr2mTDURB3csBWCOv9lm6MOJ6QA0KjHkZyzaAHo/RR4o4pIhNKHufH2/8=; 25:K0HZBl484ggD1e4KzWuk5rIoisH/0uFZKEbVYWS+3CYjaV00rdl7/iUlAWA7hewsTTHfizzbC9nOwl9OoW0kRqekg7f5Or6gXGO5fmHGyjSeU2vMGRxWxtlrYPcu1sI+yaJPOhGtiWolnkCgHdIZog/g+MmUvvC3qD6N1VHQ4qC4GHxACuB3Wp6Cq7ibdo9xWukQT/NOiggOczWGqNAq52cVAwyJ4w0C3T8eDixkKZ6Uz3CKotJnu5BLIBuIWQEtv0o0/X45x3yRIx5nejGOjlS3mbYFTqBItX+FN4UJgpqMsluqz13Xlp8fqpYcv+3qNeJp92sh4+MCRjqpeQolDw== X-MS-TrafficTypeDiagnostic: BLUPR0501MB2065: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 31:kFpHDT95nDTlUODMvjIRRb8LbTBvj5OQc2GZGJUoRywmZti4hwvx/uzgLSVcsx8MSEBteINTKkMZ3V7KAhRbFEgNN+N5JY4mS6UpGOMmkm6FclO2qYSQ4IMWgqVXBv9SHN4g4tG9Svqyb1SPib6UcVWCtvEvbDsL69PCp8EUPDpCwswezNaLaKgGFj9Ktj0FiCi70XAcXpT2EZBbflrF6s33jQHc7tIoEYlTmePSJMM=; 20:nJvxnGMk5wP7BvfQFmCbgogg8aYiCWrwnBWTt+X1lmCHxks8Uw1JyZeX3K6OrZydVEBsSj1jE0nN3/Z8TYfEsKAJ8drhF44n0CNdrRpJ4ABMYmTWxQszkgdm3twJZcHsBB1in+vMBUg6M0orxETpq7X4tOBa7Higvrp4Q05cyA1C2z6kNnUtgGKQgiUcMVC8dnTRkauJKJxDw18BUNGKNHa6IsHL1A5FX2MEMWAT+4P4IHppJDhHN6q6XSA16pcQgivZ9wfn0w6v/HbvVZiJr20iqBQKiYSd2HdOFuaz+tkeF/ZgNCxBk6spmgpZ5JITirdj0XP9KOV7GNN3mYyAwnroc14V3nD4n3xkRMyMskKFdlG2tOXO9KeV+uRRTs8DIh4hsvBVrU8UlA+ZQ7H5CzYvje2547mJxAsYOSuM3tICixd3eTFwJDIML4Lz/f2duXrfEK3Z4cuUAOWiz/RPxILsM+WP+si2Hr2tVBJ/PdHPm2/IK1Z8S+Jp++VQ4JT6 X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB2065; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB2065; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 4:ErGrXDGrlwGWZIOV1CcWooL54VeGNc43G3XUHBQPmVvz0ykXC4LsXZpTtqcWZqwDIqj5FEYuS7cva5Jm6sQ4dZe6PTAfTYPLmEcS/fGnDGOLqGES7rkG0BXenXzKgbVrhPmKmLGXVRl0oONQuH6EQTglNgGjcEmsnPyGbYrdmllrMH38wqZnwVeNgvJS027hbaFdrgUdAubkGKXSAB+yIanLNtnm0rv1xM7J2QXg0jK1BOkl2tCUUO5CZ/SRo+o3AesbVJx6DeNuBzEyfijMObZm3rlrKHMhnMfo/8dHVcY= X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB2065; 23:KTIX75hratxz8VU/G8ZmWbGWvr/gBkrdxLvA/E+?= =?us-ascii?Q?VwGTavHRPiM3kVlAurdCfIqLG5Wheh3GGNjt63wUz8bdHQLHnaJhDBnX5969?= =?us-ascii?Q?WH+pS6ReE7Xe08JVBCODDleRKD/XIfaMLeOrh7g8vSvmLw2PDrVRDsO5NtA9?= =?us-ascii?Q?MwkpZjraQTk6bkbeSt43eKO2uAdJfYMy52a+DWix29PLeS8MYJEinWVkdnyx?= =?us-ascii?Q?OTTO/gz/eAgb4gfBbz0Q3naomFPt2vTKSFrN8X1VsVXBaDU5fVNfQFIr+F4x?= =?us-ascii?Q?r4IKl6J3RIr9oZWPB1DxLkVlPqF3rUSdAwexkM6bK6zn9oVFVHGsJ/O3Mu2p?= =?us-ascii?Q?e9l+X8faerOD/DIG3g+5P4h6LzumD+aNoT3fUdRGefa7thQ9ML2kkSOKQ4jB?= =?us-ascii?Q?Glsih4T1LSi+Fn4x53GgYXsGQH3Ep5IMmT3i4IVgOq4Xky22w/zrvvlI25Cl?= =?us-ascii?Q?qGgp7J+BbGfRzel7H6JPixCsTQculbzkuV+6hFwnDZ3Rfl2ZLG5d+1s3Ppc2?= =?us-ascii?Q?2WDOuJ0Kh6vLEGUYFp1XnTP+SZHQNUA1XGpwi/1dNDhFoHbuhn+R8opfYO06?= =?us-ascii?Q?OKdeKn7W5bDkc4nW4p+QIQzWVAWporCe0f8kxQdmib+4uhETC9ORv9IXTxxz?= =?us-ascii?Q?bNRb1HVMTUtEZRk3yVroAbMP7t0enSfYXpe7rVVomShxEcYQrcafWW90rc+e?= =?us-ascii?Q?hrFLSM160bVRTEv2I92ldm/9X0O7khSgdcAeEWWXGg4Fr9MEvryp3BiPwXKb?= =?us-ascii?Q?28CCrXJesQu3g5GxpBEm5xhCBp2x2xL3Zj/aeUFhXCx5sN1ZiUPA8cbEBCOW?= =?us-ascii?Q?dhHhK7hRF1OjCgaTFOakAkrqCXE/oLWjsIffRtvNRbeOursJqod7pyqr0a4v?= =?us-ascii?Q?p8jpknKC+Qkk5qe0OEqf2oaxbfn0TFZ1GTfQ+Mrs3k0/OjAXS42pTGPo1u+q?= =?us-ascii?Q?31iBcj/MeZgHSkIxMBmVx1D13XAUGE51SUCudloyxZL3tHt6pALoIZiwUuOF?= =?us-ascii?Q?zY7oEEVXh6xXLDMyOcyk+U38vlvjLGHvJWkCP84wgQGu+SAyFrtRKYrDpgHZ?= =?us-ascii?Q?zi7S0/X3UbQ85UxeIc57XCGhoW7emIApS/mCQB+Sd7CdA2Y6/FJDIRsvJrU+?= =?us-ascii?Q?9qGP1dCixUpuzc3NWxrreIoJrim9mfzuJkUUzMsgTP67uHP5HIcMV1v0SAWf?= =?us-ascii?Q?mncK8DryI+3ypHhNhdrgM4L8wwoTsN72qjtKngeTO/VYDH5QfMVU8Y6D18F/?= =?us-ascii?Q?nBQ4ieGZB/gXxnv4excICiRFXaqredHDv14dlBv0V?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 6:NUworB7gHuvqgUPDRCHx6yTlqYcJDokxCRPsNjYSYHw3fO+X2Uo+oZFJKGosE6/h64r/4YHSTnsu9coaC1/MiIM0EkZ+P+3rQwv0SuG0bH037YCgOqOq8pxKc20FYQy+1R0hXI+kwPnxxIJXT/+uEh+zmgXP1xu5fpb6MmVDNEfej01WCmKIRCCPfKW1FJksbaZmWceR0xomFz/v8P3uCbYazqNvUiUfXjAQnOPrTanqienq92DE77JV44QCakVGKs16idJHN3ooQpHyNpIJEtVpDT/hXI9d7ftyrfaF3AT4Sa3q6mEUOdTHxHnu+cVLN3sxvgJUEQMDNg+wcPl+tg==; 5:6i2GMrGc6TZMhxQ4ZqNzjEOo+x1iQccltwilC9sMqL4/ax1/irTQcEXF2VaBCU0Vx/RQNZIYzEb+oXIpmNjlvQnJBR3j8ugT9rxI+GDvbeEOBDkQ/uIq8S17yGImWq9v9Y/yZCddk3JMJNhg/3tZjQ==; 24:Q5Owo3p4PjcrG1Uy8Re7XPymina/mOWfigXYOMOD7lBj4woBbWlmDHvpZt5mMp8qNAC7xp8lDzn+FHWnwZfrCyU9pSvkICqEx9l0QPh6G60=; 7:Y2xdHZ/6VrkmDp+kqQLZNNZWca/8idsoRUOo5oOezSpeZqn6kCXVZOUuEieySph/OBzsLRXtl3ASbAym3Y8qRLZRiQTZjwnG7FgD09VaQcyAHp3re9nJJTARXkNZQVO7GNKrwyZhimsiMkVgCi851DzHLt1cKXp0jNLQtHU6u7t1/knT3M5pLMPlHzXtkaLczNgIUpTLbVE/syj2/vUdHLy7Let2yHugz4tfmNNavME= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 18:27:02.0872 (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: BLUPR0501MB2065 Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 18:27:07 -0000 Mark D. Baushke writes: > Alexey Melnikov has entered the following ballot position for > draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection > > > RFC 6234 must be normative, as it is required to implement this document. Please advise. I ran https://tools.ietf.org/tools/idnits/idnits.pyht on the updated draft (moving RFC 6234 to normative) and got this error: | Checking references for intended status: Proposed Standard | ---------------------------------------------------------------------------- | | (See RFCs 3967 and 4897 for information about using normative references | to lower-maturity documents in RFCs) | | ** Downref: Normative reference to an Informational RFC: RFC 6234 | | | Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). | | -------------------------------------------------------------------------------- Please advise if I am required to put RFC6234 as a normative reference, or if I need to follow the idnits requirement. Thank you, -- Mark From nobody Thu Sep 14 12:21:37 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D24132A05; Thu, 14 Sep 2017 12:21:35 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150541689558.18941.12534261280015962025@ietfa.amsl.com> Date: Thu, 14 Sep 2017 12:21:35 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-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: Thu, 14 Sep 2017 19:21:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption WG 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-08.txt Pages : 7 Date : 2017-09-14 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 including an errata fix for checking the Peer's DH Public Key. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-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 Thu Sep 14 12:52: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 3B7321241F3 for ; Thu, 14 Sep 2017 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 ySml17n8m6YH for ; Thu, 14 Sep 2017 12:51:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0F427132335 for ; Thu, 14 Sep 2017 12:51:59 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8EJppcT009225 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 14:51:53 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "Mark D. Baushke" , Alexey Melnikov , The IESG , draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> <3253.1505310397@eng-mail01.juniper.net> <39647.1505413606@eng-mail01.juniper.net> From: Adam Roach Message-ID: Date: Thu, 14 Sep 2017 14:51:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <39647.1505413606@eng-mail01.juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 19:52:00 -0000 On 9/14/17 13:26, Mark D. Baushke wrote: > Mark D. Baushke writes: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection >> >> >> RFC 6234 must be normative, as it is required to implement this document. > Please advise. > > I ran https://tools.ietf.org/tools/idnits/idnits.pyht on the updated > draft (moving RFC 6234 to normative) and got this error: > > | Checking references for intended status: Proposed Standard > | ---------------------------------------------------------------------------- > | > | (See RFCs 3967 and 4897 for information about using normative references > | to lower-maturity documents in RFCs) > | > | ** Downref: Normative reference to an Informational RFC: RFC 6234 > | > | > | Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). > | > | -------------------------------------------------------------------------------- > > Please advise if I am required to put RFC6234 as a normative reference, > or if I need to follow the idnits requirement. Since I also made this comment, I'll try to clarify. The guiding process here is BCP97/RFC3967. In this case, the IETF has published another organization's document as informational, which is a common reason to have a downref (cf BCP 97, section 2, bullet 1). I'll note that RFC6234 is already in the downref registry (https://datatracker.ietf.org/doc/downref/), which means that your area director is allowed to waive the requirement to call out the downref during IETF last call (BCP 97, section 3, 2nd paragraph). It's EKR's call, of course, but I suspect this is the route to take. /a From nobody Thu Sep 14 13:36: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 A834A124319; Thu, 14 Sep 2017 13:36:26 -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_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 9NmTdx36_BeS; Thu, 14 Sep 2017 13:36:25 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E533813207A; Thu, 14 Sep 2017 13:36:24 -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=sE+sR4nI/qYuPuvWAfRcp38HD1JmECsxw2kjZsXCPvY=; b=Zj0b6pe0jx30YVtamcaOnhtOSzjrBRWppoqTYMqsifSyMIEf/NlwJm24r+gh4vqfFR1MmoUXCeEK4UJC7lyskHcp0gEGP7eql+vWUlI89TWIb9r/+w59SwNaU62WOIACJia6ej4ww/Y/KhHhNVnzOQiwFAfAaXrJqY6hsSHAP2k= Received: from BN6PR05MB2916.namprd05.prod.outlook.com (10.173.18.137) by BN6PR05MB3315.namprd05.prod.outlook.com (10.174.95.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 20:36:23 +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.20.0077.006; Thu, 14 Sep 2017 20:36:23 +0000 From: Mark Baushke To: Adam Roach CC: Alexey Melnikov , The IESG , "draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org" , Daniel Migault , "curdle-chairs@ietf.org" , "curdle@ietf.org" Thread-Topic: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) Thread-Index: AQHTLIXmpL2DbKWsSUyMWgGWPWrsiaKy1HY3gAHgpNWAABekAIAADHiA Date: Thu, 14 Sep 2017 20:36:23 +0000 Message-ID: References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> <3253.1505310397@eng-mail01.juniper.net> <39647.1505413606@eng-mail01.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [8.36.116.212] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR05MB3315; 6:fsioApOtbvBfiLrsbbkbJhcUVIkSqEMW+GsAxe39jsbfvSWMSrMNHfrPlcvqwsKnPYrOQHGnUFa3pym6SdJCBUaeOnnEqf4mWurIyriNaLgkCmHJMqAbguVNCzhFpUXfVlYhdrXFLGOaF5rlGyo/KbyYIwH148OMSoHhZE8rEBgYZOPIxFqUGLgtbCn5KRWjphT9utYlCwpC2x6ncKuRBFjUGcSdL3kMhpdLogfJdERdYsO+Ccwm8rohC0dbyoGJbHMkVLgiDeEPvdwUEOrO/0v4QcoQ+3dCNtY17dW1PQD5fJhHyUHSJpY8Ct7sbZkiJA+fpl6iAj3ou4ebQ+SetA==; 5:8Y+EW2a7vR+m8mhfc9rm/OZlCzO0llSaC2Zqu1mAdZxg/MJyLgVj+E8GjpCnm3h/gSINolHgasRymVdb6Qd7/gY5OMAIvM9hUywEZy87VWg17BCx4RWwOm7TT5f1B0nn8yu/fV8vUDzxkP8tFD/xxQ==; 24:2XvFaFvFt436AKP6YB0LoejQV1JNdP9LT7slH7Cna8JDEBXTVIBcxqk8uibKXDdDfz9kIaeTtlnzefNDtapfBXVV3rFCM0FS1yrg0k/ULT0=; 7:TVXTae5EuY4ikbRhyZHh01JS5Wq3N/jC3Mmx28IMLnGQkDcFeGszVl3hXk5fHphC5EliRH1S2QxM+qY5uA0pqax6+3mCuZn/JtZ3W2/bnwNWbS4vtKUAnzqATtL+asGrbOJUnV3tqti+KTpNuJOV5eIoOt0A+xBxNjX172Z71wMO3QRq4BIAikTLyEKp0HGimKMRxPod5FjiLPqaaJ2gs3UM4eVFgTlQiP7UkvQz7V8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 693a8849-261b-42c9-50e0-08d4fbb043d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR05MB3315; x-ms-traffictypediagnostic: BN6PR05MB3315: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mdb@juniper.net; x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3315; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3315; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(377454003)(24454002)(189002)(199003)(6916009)(76176999)(54356999)(50986999)(7736002)(305945005)(966005)(3280700002)(66066001)(478600001)(4326008)(93886005)(101416001)(97736004)(2906002)(3660700001)(53546010)(83716003)(2900100001)(105586002)(106356001)(6506006)(2950100002)(77096006)(25786009)(316002)(229853002)(6486002)(6436002)(81166006)(54906002)(110136004)(230783001)(99286003)(81156014)(6246003)(68736007)(8676002)(102836003)(6116002)(3846002)(86362001)(36756003)(14454004)(6306002)(189998001)(8936002)(33656002)(53936002)(8666007)(82746002)(5660300001)(6512007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3315; H:BN6PR05MB2916.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 14 Sep 2017 20:36:23.6432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3315 Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Sep 2017 20:36:26 -0000 Hi Adam, > On Sep 14, 2017, at 12:51 PM, Adam Roach wrote: >=20 > On 9/14/17 13:26, Mark D. Baushke wrote: >> Mark D. Baushke writes: >>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection >>>=20 >>>=20 >>> RFC 6234 must be normative, as it is required to implement this documen= t. >> Please advise. >>=20 >> I ran https://tools.ietf.org/tools/idnits/idnits.pyht on the updated >> draft (moving RFC 6234 to normative) and got this error: >>=20 >> | Checking references for intended status: Proposed Standard >> | --------------------------------------------------------------------= -------- >> | >> | (See RFCs 3967 and 4897 for information about using normative ref= erences >> | to lower-maturity documents in RFCs) >> | >> | ** Downref: Normative reference to an Informational RFC: RFC 6234 >> | >> | >> | Summary: 1 error (**), 0 flaws (~~), 0 warnings (=3D=3D), 1 comme= nt (--). >> | >> | ----------------------------------------------------------------------= ---------- >>=20 >> Please advise if I am required to put RFC6234 as a normative reference, >> or if I need to follow the idnits requirement. >=20 > Since I also made this comment, I'll try to clarify. The guiding process = here is BCP97/RFC3967. >=20 > In this case, the IETF has published another organization's document as i= nformational, which is a common reason to have a downref (cf BCP 97, sectio= n 2, bullet 1). I'll note that RFC6234 is already in the downref registry (= https://datatracker.ietf.org/doc/downref/), which means that your area dire= ctor is allowed to waive the requirement to call out the downref during IET= F last call (BCP 97, section 3, 2nd paragraph). >=20 > It's EKR's call, of course, but I suspect this is the route to take. Okay. I will wait for EKR to make the call on this issue. In the mean time, I have published revision -08 which I hope addresses all = comments other than the RFC6234 issue. I am open to any additional changes needed to progress this draft. Thank you, -- Mark >=20 > /a >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Sep 15 02:41:34 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB4132F76; Fri, 15 Sep 2017 02:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.fm header.b=33PPrHFS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mFl4d7CW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90kMaatLjHJQ; Fri, 15 Sep 2017 02:41:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907891321BB; Fri, 15 Sep 2017 02:41:30 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0331220DB4; Fri, 15 Sep 2017 05:41:30 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 15 Sep 2017 05:41:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=20gBXxKBbQ0DQJvH3hynOfMx46ecx S5tEDGLWlORGr4=; b=33PPrHFSb2ab62tR6wf/NWqwvCSJGB8rZhyo1bCVFhcFg ryHWAs0yDOxW2lxGkBmuWKrpouIF7kBJ2pthQ6kRceiCRTHGA8x3IdILv+CLyb15 bwpzm8A4xOL9GgKZ4ZDtTVjFuau4FE1NGcZgppnmm5XL0/4Yn1f+uz8I6ii4fSI6 W0rLHb7u55p3v4YlDciZjydg9WAroV8gMtxC3J8Jyi6Mz60IN52SXmowFO9XYLDy vaF3FmcnQPDNkh1bhrEvI4VXD/sgdSeUAiNkbobb0Hrqup0s0anI2eTUzjlMC8kl +n4SIAMSwijoU/OYlBcNV7doB925meoX+TRbjmFew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=20gBXx KBbQ0DQJvH3hynOfMx46ecxS5tEDGLWlORGr4=; b=mFl4d7CWlByIp5h1ipAWBR HpNoRoT5+L5qvLZ/gmEct6cYd4Rs/22KiSiHULTPnE49vK8hG6Mo8nMwJiwPsoc0 jZgF45vlywZLRvN/77wEQZec6n86N/JEWPm36Mw8t3pjhYD/fYDm/Apj4gqqusRh q9LBwT4UF2tKkXx/NAvW5UHvvdSQW5je3IBsDvIDJmkDVpI0aNC0dlmvUVxEmSJ5 OYENstsKqrflwvgpdv/sFcOE4UTSVPhyUeli61MJJlpjCe8vNqzt5Ef6vyHIOUKE ju8eswGGFgdslSJovRyangxAsnTIM5FyWpsGQ5aOPxM+Nh/5YWYaww5moHaBlq4Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D38E89E2D6; Fri, 15 Sep 2017 05:41:29 -0400 (EDT) Message-Id: <1505468489.1399722.1107025704.592DA5B6@webmail.messagingengine.com> From: Alexey Melnikov To: Mark Baushke , Adam Roach Cc: The IESG , draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 In-Reply-To: References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> <3253.1505310397@eng-mail01.juniper.net> <39647.1505413606@eng-mail01.juniper.net> Date: Fri, 15 Sep 2017 10:41:29 +0100 Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 09:41:32 -0000 Hi, On Thu, Sep 14, 2017, at 09:36 PM, Mark Baushke wrote: > Hi Adam, > > > On Sep 14, 2017, at 12:51 PM, Adam Roach wrote: > > > > On 9/14/17 13:26, Mark D. Baushke wrote: > >> Mark D. Baushke writes: > >> > >>> Alexey Melnikov has entered the following ballot position for > >>> draft-ietf-curdle-ssh-modp-dh-sha2-07: No Objection > >>> > >>> > >>> RFC 6234 must be normative, as it is required to implement this document. > >> Please advise. > >> > >> I ran https://tools.ietf.org/tools/idnits/idnits.pyht on the updated > >> draft (moving RFC 6234 to normative) and got this error: > >> > >> | Checking references for intended status: Proposed Standard > >> | ---------------------------------------------------------------------------- > >> | > >> | (See RFCs 3967 and 4897 for information about using normative references > >> | to lower-maturity documents in RFCs) > >> | > >> | ** Downref: Normative reference to an Informational RFC: RFC 6234 > >> | > >> | > >> | Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). > >> | > >> | -------------------------------------------------------------------------------- > >> > >> Please advise if I am required to put RFC6234 as a normative reference, > >> or if I need to follow the idnits requirement. (From the department of pedantic IETF process :-)) You need to make it normative, as per IESG statement . idnits just tells you that there is a Downref, which means that the document must be called out explicitly in IETF Last Call, unless it is already in the Downref registry. Downrefs are generally not a problem, they just require special process. > > Since I also made this comment, I'll try to clarify. The guiding process here is BCP97/RFC3967. > > > > In this case, the IETF has published another organization's document as informational, which is a common reason to have a downref (cf BCP 97, section 2, bullet 1). I'll note that RFC6234 is already in the downref registry (https://datatracker.ietf.org/doc/downref/), which means that your area director is allowed to waive the requirement to call out the downref during IETF last call (BCP 97, section 3, 2nd paragraph). > > > > It's EKR's call, of course, but I suspect this is the route to take. Documents describing hash algorithms were/are published as Informational. Which means that they are always Downrefs from Proposed Standards. Once a document is added to the Downref registry, there is no need to call it explicitly in IETF Last Call for other documents that reference it normatively and the warning from ID-nits can be ignored. > Okay. I will wait for EKR to make the call on this issue. > > In the mean time, I have published revision -08 which I hope addresses > all comments other than the RFC6234 issue. > > I am open to any additional changes needed to progress this draft. > > Thank you, > -- Mark > > > > /a > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > From nobody Fri Sep 15 03:55: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 3471E13292B for ; Fri, 15 Sep 2017 03:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=hackers-mu.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 cy5QWW1tfrAa for ; Fri, 15 Sep 2017 03:55:06 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6CE132026 for ; Fri, 15 Sep 2017 03:55:06 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l15so7384191iol.8 for ; Fri, 15 Sep 2017 03:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=neMWUaRcUx0NNS7Q0CCqj7xxME2k7zaioG1mji5Q9cA=; b=Kixcrx2StK9Qxm3klfbZmSb/6HnsbI59ER++Lj568jBvMGZlOVLbgbgUV+O2/CZgns HurVYv/ysc9S7VaWeWf0TJLKC6RWVePmSzRH74lxyotvQZH/2Y3FcmGT8Tl/W5oB7owy IL8X1vLvQK1FyDIdkkJTN9LhMobNS5HDr/uYyH7r5TwW9sG+XVIj+QLihOgeQ2T1LJdi 9qQrW097cUAGHWJ0vl/f3mZkn1dSA3ud1EkH4JLzk30Pe3hZJFyML6O8psFRp6X9+Cph DDzmo5vUu8uUDKy334uo0nxEi+pZk22kZekcXo0kbnCVQPEuRg9D4+GGlWVF6BB7jjiE BxEg== 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=neMWUaRcUx0NNS7Q0CCqj7xxME2k7zaioG1mji5Q9cA=; b=isfh2ICLJ7gbXMOcZLxlRgumG5QStiYyJn32FNlbNPKnH6ioHB4PV8OY3f3fppi29d hzf0Jw0p3Fx6i3bgXcP0xRGEX2j/9saiS5nG0m8sslWAm2Q+rWdvJXWEBRuNwrrbVO75 D3rmkrjRP4zJKuOBf599iTKN3JVHgY76pGycDhfak2acExY2qMaiCqyXX3r2lOCa0DH+ 8XGDatCHl9RdS/KHeqcbd2SR1DJ3KPRvgZSvA8HdAYfzLB0hdt6KrSY8KS5FZ4evTrGc /3H5Ufs8TYwV9dt2AEgXvfsi3zWWYd4pNNvPc3Jvv+MR9cGWMKMuSahrkL4eHFFgJpxB 39WA== X-Gm-Message-State: AHPjjUis945us/L/nrQ4vJ6xQuRin4PJhLTjZZP1mEemiGHwvUaInK+i 3Me6vcKz1vhs0z75d834EMPLBy3GSkm4J00+iy2U4w== X-Google-Smtp-Source: AOwi7QC8MlgC6czJ/BnDg1p+WB6GoaC+MSn9dvKzr5R6h/31v5uncGZwvwFP1pspCTa+xELCChcDArCFzMPCcy4ABvg= X-Received: by 10.202.56.135 with SMTP id f129mr14342061oia.4.1505472905552; Fri, 15 Sep 2017 03:55:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 15 Sep 2017 03:55:05 -0700 (PDT) In-Reply-To: References: <150533146908.30532.5312387197836535820.idtracker@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 15 Sep 2017 14:55:05 +0400 Message-ID: To: Eric Rescorla Cc: Ben Campbell , curdle , draft-ietf-curdle-ssh-dh-group-exchange , curdle , The IESG , Daniel Migault Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Ben Campbell's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 10:55:09 -0000 On Thu, Sep 14, 2017 at 5:45 PM, Eric Rescorla wrote: > Hi Curdle folks, > > Could you please address the SHOULD/MUST issue raised by Ben and Kathleen > > -Ekr > > > On Wed, Sep 13, 2017 at 12:37 PM, Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-curdle-ssh-dh-group-exchange-05: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I share the questions about "SHOULD" vs "MUST". >> >> - abstract: "insufficient against state-sponsored >> actors, and possibly an organization with enough computing resources" Hello Eric & Ben, Concerning the "SHOULD" vs "MUST" issue, we thought about it at the time, and we went for "SHOULD" for backward compatibility. However, if the IESG feels strongly about it, we can change it into "MUST". >> >> Should "an" be "any"? (Same question for section 2). >> That's a reasonable suggestion. >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Fri Sep 15 03:57: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 1DFBD132D4E for ; Fri, 15 Sep 2017 03:57:17 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 Axrrmsl4gqKz for ; Fri, 15 Sep 2017 03:57:14 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 9E877132026 for ; Fri, 15 Sep 2017 03:57:14 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id n69so7446294ioi.5 for ; Fri, 15 Sep 2017 03:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o4yfcQdLF9SNj3HXyFN3h4u47iRQtaz/NiraT5iRIZI=; b=in+ximB1hgh+HlW3t0Hj9AXzYzl3tsZFQyXbdBtyelcb72K0USaxd0sfpYry4wmEWX nhCvoWrmkm1a1JYeRpkYKhrS09wKwsjybvUsridCroyD4gKuaTFnp0dz5V0Yav4v/WOM RnzJGpeWUHbOS6sTUPd5J1hXxImNVnXLldA/NgDfGWl7G2sOjSRCKjIFvUnooiwYI3Pw wQIIY7quECFZBxeQsq/rnJGzSs4x9cz8zg0uV+1I+z9bgC7MLbtyd/lV/XMQ+EUqdHsU 3xsxMNsG0Pg9USjCwGm/ncR30uWz7p5egflgItJ6RFPve5RCFrAGTPwPttHtl5F5KeeO yzqQ== 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=o4yfcQdLF9SNj3HXyFN3h4u47iRQtaz/NiraT5iRIZI=; b=tT6TDZHxYgGcXMeV651yHz8Ac0+AwZmNkgLPfEQXWF10jk8NN05cPrMYXwc8kU/LJD gCRmTcDjtkBIPZpNm8XpI+Nlbl76W+TQMjqtkDJKagPEbuVepocic5kuoQdnTBeUfLN2 IGcm6TCmMu+s56EbIdg5SAj63xDv/VvDKjBC1cwvjAzS013y+mqqTHMdHTpiVLMd61b2 4Q/ca0lFFNEyPuVblA8gcshEezirmpgCNy1wnz8i6HuekWm+qXPkgJPMGufWmOVU9Wbl v7LAjvO158cyFW8UFZccL83QzqDoIFhOyGsSVcjUvUzfseeq8LFeUiKXpQikb/aqKGtI i6rQ== X-Gm-Message-State: AHPjjUiNZy4k1b0Re6Ypo819VJnphuuCEFpLLes2vPhRpbYi7iWyIO3j vfkW1cTIPwIkpj32LGpaJr5iMyPv5ayJcvEfsAxAOg== X-Google-Smtp-Source: AOwi7QCcwJ4w8TSj1AgArmTjAJurnUgZD2fPOGyvZfNDETK5QUP9QT+mpqx63JpTfUERCb3oeGoc379wbkBmBHHYBoQ= X-Received: by 10.202.217.4 with SMTP id q4mr9791572oig.283.1505473034045; Fri, 15 Sep 2017 03:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 15 Sep 2017 03:57:13 -0700 (PDT) In-Reply-To: <150534254545.29051.14338755931682118188.idtracker@ietfa.amsl.com> References: <150534254545.29051.14338755931682118188.idtracker@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 15 Sep 2017 14:57:13 +0400 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-curdle-ssh-dh-group-exchange , Daniel Migault , curdle , curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Suresh Krishnan's No Objection on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 10:57:17 -0000 On Thu, Sep 14, 2017 at 2:42 AM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-curdle-ssh-dh-group-exchange-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > RFC4419 specifies an example in Appendix A that uses a 1024 bit safe prime. > Shouldn't this Appendix be updated by the draft as well? This looks reasonable. Thank you for pointing this out. > > From nobody Fri Sep 15 04:01: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 A0FC813309C for ; Fri, 15 Sep 2017 04:01:48 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 ZHu4lfp69g7P for ; Fri, 15 Sep 2017 04:01:43 -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 B30611330AF for ; Fri, 15 Sep 2017 04:01:41 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id i197so7421689ioe.9 for ; Fri, 15 Sep 2017 04:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qDEPlTn+dat9jzNIz525ULn8C04hDpt7IpUFJKYiwvo=; b=mnNdZSBeD+ugCXWi+fsgnHExPc7X1jBMu7oVgPO40M3Vu+rtwa85ZktBry2owhn39o LpS1TuzNZ9nL5W5x17+iilNlQhZRFk2WXzEETi1uNPoiBktPAr9VhTY8fqdXOkLWJl3g 8Lu+jPUX2N3lMdt6HNzzwtsSL2La3+zsm/Cgun/CtbZKILsJno3kpqy6G7JX0C3iBj6K 6bohYfjhyO/VNWw1sb4+fQiFEo+UCj+gKaMSw0OjnPUUlwpdIfHIFMb73NcmPszoPJYl rSOlLfkWp1Oow1ZcGZI0qSyAWMdp0yXPMd3rtZ1p4oZAqbURhbeYdrXcpCOvQrbYSqfc q3Xw== 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=qDEPlTn+dat9jzNIz525ULn8C04hDpt7IpUFJKYiwvo=; b=CQDIoSTL/TO2+pGvCFYUDlAu6RxvgiNgVJXUElvBsIXpNf5qAeXvchGp6u7RJUkQS2 llSmipIXZuxFbrwHAgAMVuKVgJBhQG348e/Ia94CFwDjqOCC8af26yoohtTXXwfSQUne NCZ4zfzhj3BBzPPDR0GPJ/ZE537L59Nz2w4Jb5mo5cfXu9U1V7DBmsy8TtC7t5iLemGA abOPDcVqsxRGw2dkwSi3vIluQMKTtfajKKdHOiI7v7RKn8n76guQrFMgBLwi8ApfAGJd SVUeux3QttMVuzltF7euGn2Ay0bHTDBWf74OVlnKzv1Nf3fECQcaKikOAaySsEqjRh2h sbaQ== X-Gm-Message-State: AHPjjUiwzFDAbHzhs4scgLe6sxvPHNQWsQT6VdX2WrGEzIAPAMJgI2Hb 8z1TcgB/AVSMcVOhlzU5vDQfMRNiXu5P1y63TtCtOw== X-Google-Smtp-Source: AOwi7QCBWeoKNT0Bu4F2xxcxOPo/qbc+3X2cUDz2jVwcTz0/lu/XboaAWRTynZa22paTlvgTnGG75IcBwPLh6b+cL3M= X-Received: by 10.202.224.70 with SMTP id x67mr19510523oig.31.1505473300850; Fri, 15 Sep 2017 04:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 15 Sep 2017 04:01:40 -0700 (PDT) In-Reply-To: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 15 Sep 2017 15:01:40 +0400 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-curdle-ssh-dh-group-exchange , Daniel Migault , curdle , curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 11:01:49 -0000 On Wed, Sep 13, 2017 at 10:08 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-curdle-ssh-dh-group-exchange-05: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I do agree with Spencer, the text that is non-normative reads as if this is > fully deprecating any recommendation below 2048, but then the normative text > just says SHOULD. Is there a reason this is not MUST? I know deprecating > things takes a long time. Yes, it takes a long time, and also because of backward compatibility. We felt that "SHOULD" was sufficient at the time. > > From nobody Fri Sep 15 04:08: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 447481330C1 for ; Fri, 15 Sep 2017 04:08:14 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 mYtgB74aoZoC for ; Fri, 15 Sep 2017 04:08:12 -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 51EA81330BF for ; Fri, 15 Sep 2017 04:08:11 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l15so7457597iol.8 for ; Fri, 15 Sep 2017 04:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LmW7FBcZB/hNG1F9TJyFENOqwgIXQLoIUZni6Chi56U=; b=WrAVtJn9qpNZ+AbHpljp1hiVHvCb706L0O+3MVk6Fnu14SCLrysmextDqw+Dn/KeJE 7zqLCP1B8svxISLTio4FTPF6o2Au9uWYQwB76x22H3ETgEAPkbXuFQ4cqs3johJ34T4K 3lNWlfV9QbqCZmG7b1hu50RLZCj4UVfVKcowavXG1J2Yu0AxfbbXa/06LMO6x+TlshiS NtKAlvX4H8V0LIDkzU2uv3CBSmxsbzMf3eEjapjk7nv0hKl12KZSMj23oIv7RX8l9pNh 0YJfu+EVTrJjRLMUKEuUTpW5jaV+bc7W/tWTQzk4pdyMLpeRVFRp64vQ5Dz5YeUlIR8F 7kfg== 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=LmW7FBcZB/hNG1F9TJyFENOqwgIXQLoIUZni6Chi56U=; b=eXUa2h3ou8kD/uZ+o3ZoAXb+JdKOTuEfxrq3q13fN3w5l4veVWuJLERX+ZQ9LLxlH/ 7lqm9Lq+fCcduUSjU2nFzG3lkWC2WwGmJlv6Ps+mCg6ueqDrRjGZUurPIvkXGmzYfKru qoZaxGFaWXu6rkv3ueY/zg9AJqrNCtFv6eVcWXa2ExKegi+jgWYTv7go02nFzFoseekV WN3uqDsUamzviPNntbyGdvEZef63BbctxhHDr5Yhm7tFoehgL9lI/xqIG+6a33vbf8RD O2QZQhPTjs8M9Cunt6oI6IatqXewX29Gtm3xquvSU0gp9MzaL03gz+6hApenGZucLuCA qi/w== X-Gm-Message-State: AHPjjUgESdGkVdKj1BK92KwC5ODuJXFxXgmcl18S879b7dxGgO0DgvGx fOSlQxbIElJa0UV+Ev2jo0blUMgcmVrtPA0dF10Wjw== X-Google-Smtp-Source: AOwi7QBneGTf9rzrYfse740+2D0i5kL35HUpArJngUMlyVmdeqWz33fFbSyEKAeXrWoBngRKutSVcABJEPDUtox3EXc= X-Received: by 10.202.217.4 with SMTP id q4mr9830757oig.283.1505473690632; Fri, 15 Sep 2017 04:08:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 15 Sep 2017 04:08:10 -0700 (PDT) In-Reply-To: <150533995994.30425.14473077119451200331.idtracker@ietfa.amsl.com> References: <150533995994.30425.14473077119451200331.idtracker@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 15 Sep 2017 15:08:10 +0400 Message-ID: To: Benoit Claise Cc: The IESG , draft-ietf-curdle-ssh-dh-group-exchange , Daniel Migault , curdle , curdle , shares@ndzh.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Benoit Claise's No Objection on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 11:08:14 -0000 On Thu, Sep 14, 2017 at 1:59 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-curdle-ssh-dh-group-exchange-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Sue, in her OPS DIR review, brought up a good point. > This document does not indicate whether it is wise for the operations system to > log a report if it receives a less than 2048 bits. Would this enhance security > or provide DoS attack surface. If logging creates a DoS surface, it would be > good to include this as operational advice. > > Interesting. We did not think about this at the time. Maybe it might help, but I'm not aware of any SSH client/server doing this. We need some time to think about this. From nobody Fri Sep 15 07:04: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 A5840132939; Fri, 15 Sep 2017 07:04:36 -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 AwgyxlJu0WL9; Fri, 15 Sep 2017 07:04: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 8231312421A; Fri, 15 Sep 2017 07:04:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t127so1493335ywg.4; Fri, 15 Sep 2017 07:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ByFee6hLCxNr1UxQKL5gEa6/PM81kaEHAAcauvH3Gg4=; b=su755E9e71Bqrm1Xt8CTQtrEbVa83gr3yPYOq4IbQbv78B4sUd+FhdXGFkWFSSLDET q1uH0EnbXFKXJ5EtPD4rmEzUmbT5FhTvBK8duHoLHIplGBQgYBio6x3J1/EywClZxTfl mfRgpAVX223paG1J6jnLkojGOfKRDtyHHcPYLv7Pf55EdOTswUo4Zug0tZlxHueaS5fI toW5wD8UbItBOdsPW4AQx45ePfKieALHJuHQKoNm9zD/2LwhcQTVvIbv53sNNOeMG9Tm 2CatmhQHzY2CFAWoWZWp/5lte1+Q8Uj1G1zDEPESiZDohVb4JotXYpOlsMVNq1YoHNeQ hHhw== 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=ByFee6hLCxNr1UxQKL5gEa6/PM81kaEHAAcauvH3Gg4=; b=EppgG3Nrhx9Kt/Byr8+zy1VBF8dlek2H86qyhlS6laGRa/UBbIXR+IE5sOemQxIOo8 UlO9mMpHiOY2o/fT67vS89+BZ1oqrx6dyTWj4WcQIZBCfl9tvhSnRHpg+6xtUpVo48g2 9zElJorphHh6O2ndTeBFm2lDAbeCcIaPJYgi2aTqFSFwbeRureG31dgNVK5Sfh9cKdOA OzjZnShWqqCADqTsp6JyAFTLCGU/I/ydy0Ok6O3MxpPhnl/nDgEjssTbJDBO1QhnTZx/ 0UnyVxObYyNhg3512V8tnowkCWE/DEpgSo6nt1jM1d6zEw+Uwph8S9q2BsCV91R6FMHr 86Cg== X-Gm-Message-State: AHPjjUg3MGZ7UrD+I73MfeRCo2nHA71F/215vQmR/LQa+cCXp0510hTV OKi9cUlzMBSN0/UrolTvJk9QfNewABhOkOVEGv8= X-Google-Smtp-Source: AOwi7QBBkeUS4OM1pt7PSU1BqlKY2mE2+bWPhem1ytZCcUKzgsUTTjkQsndlklC6SN2GfbN+0AhjWj91m3fh85lC6J8= X-Received: by 10.129.135.68 with SMTP id x65mr5299440ywf.8.1505484273606; Fri, 15 Sep 2017 07:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Fri, 15 Sep 2017 07:04:33 -0700 (PDT) In-Reply-To: References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 15 Sep 2017 09:04:33 -0500 Message-ID: To: Loganaden Velvindron Cc: Kathleen Moriarty , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Type: multipart/alternative; boundary="001a114f095657e39105593adfeb" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 14:04:37 -0000 --001a114f095657e39105593adfeb Content-Type: text/plain; charset="UTF-8" So, Kathleen's ballot thread, but since she and I share this curiosity ... On Fri, Sep 15, 2017 at 6:01 AM, Loganaden Velvindron wrote: > On Wed, Sep 13, 2017 at 10:08 PM, Kathleen Moriarty > wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-curdle-ssh-dh-group-exchange-05: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh- > group-exchange/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I do agree with Spencer, the text that is non-normative reads as if this > is > > fully deprecating any recommendation below 2048, but then the normative > text > > just says SHOULD. Is there a reason this is not MUST? I know > deprecating > > things takes a long time. > > Yes, it takes a long time, and also because of backward compatibility. > We felt that "SHOULD" was sufficient at the time. That doesn't surprise me (speaking only for myself). It might be helpful to add a sentence explaining that the SHOULD is for backward compatibility. That changes the incentives a bit - implementers have more incentive to implement a SHOULD if it's not a MUST *yet*, but when the community stops worrying about backward compatibility, it could be, and then other implementations won't interop with yours. And, for extra credit, that could happen suddenly, if someone posts a clever attack on 1024-bit keys that requires minimal computing resources and includes an implementation that anyone can pick up ... so everyone else stops accepting shorter keys, like, today. But do the right thing, of course. Spencer --001a114f095657e39105593adfeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, Kathleen's ballot thread, but since she and I shar= e this curiosity ...

On Fri, Sep 15, 2017 at 6:01 AM, Loganaden Velvindron = <logan@hackers.mu<= /a>> wrote:
On Wed, Sep 13, 2017 at 10:08 PM, Kathleen Moriarty <Kathleen.Moriarty.i= etf@gmail.com> wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-curdle-ssh-dh-group-exchange-05: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ie= tf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I do agree with Spencer, the text that is non-normative reads as if th= is is
> fully deprecating any recommendation below 2048, but then the normativ= e text
> just says SHOULD.=C2=A0 Is there a reason this is not MUST?=C2=A0 I kn= ow deprecating
> things takes a long time.

Yes, it takes a long time, and also because of backward compati= bility.
We felt that "SHOULD" was sufficient at the time.

That doesn't surprise me (speaking only for myself).

It might be helpful to add a sentence explaining th= at the SHOULD is for backward compatibility.=C2=A0

That changes the incentives a bit - implementers have more incentive to im= plement a SHOULD if it's not a MUST *yet*, but when the community stops= worrying about backward compatibility, it could be, and then other impleme= ntations won't interop with yours.=C2=A0

And, = for extra credit, that could happen suddenly, if someone posts a clever att= ack on 1024-bit keys that requires minimal computing resources and includes= an implementation that anyone can pick up ... so everyone else stops accep= ting shorter keys, like, today.

But do the right t= hing, of course.

Spencer
--001a114f095657e39105593adfeb-- From nobody Fri Sep 15 08:06: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 250DB1333DD; Fri, 15 Sep 2017 08:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4FFKR5FD3Z4; Fri, 15 Sep 2017 08:06:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 13B7E1333AC; Fri, 15 Sep 2017 08:06:41 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8FF6aoQ026565 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 10:06:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_61D17367-FDFB-42A5-9733-FC718891CD84"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 10:06:36 -0500 In-Reply-To: Cc: Loganaden Velvindron , curdle , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Daniel Migault , Kathleen Moriarty , The IESG To: Spencer Dawkins at IETF References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 15:06:43 -0000 --Apple-Mail=_61D17367-FDFB-42A5-9733-FC718891CD84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 15, 2017, at 9:04 AM, Spencer Dawkins at IETF = wrote: >=20 > So, Kathleen's ballot thread, but since she and I share this curiosity = =E2=80=A6 Same here :-) > > > > I do agree with Spencer, the text that is non-normative reads as if = this is > > fully deprecating any recommendation below 2048, but then the = normative text > > just says SHOULD. Is there a reason this is not MUST? I know = deprecating > > things takes a long time. >=20 > Yes, it takes a long time, and also because of backward compatibility. > We felt that "SHOULD" was sufficient at the time. >=20 > That doesn't surprise me (speaking only for myself). >=20 > It might be helpful to add a sentence explaining that the SHOULD is = for backward compatibility. >=20 > That changes the incentives a bit - implementers have more incentive = to implement a SHOULD if it's not a MUST *yet*, but when the community = stops worrying about backward compatibility, it could be, and then other = implementations won't interop with yours. >=20 > And, for extra credit, that could happen suddenly, if someone posts a = clever attack on 1024-bit keys that requires minimal computing resources = and includes an implementation that anyone can pick up ... so everyone = else stops accepting shorter keys, like, today. >=20 > But do the right thing, of course. I agree with Spencer=E2=80=99s comments, especially the one about adding = text to explain the SHOULDs. I also understand the need for a transition period. However, = unconstrained SHOULDs leave things open ended. Was that the intent of = the working group? Is there an expectation that these might be revised = to MUSTs sometime in the future? IIRC, Benoit mentioned the idea of logging or surfacing a warning if you = receive less than 2048 bits. That seems like a good idea. Thanks! Ben. --Apple-Mail=_61D17367-FDFB-42A5-9733-FC718891CD84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZu+x9AAoJEIBWSmyV89QNg7YP/RjeYloXh4t4cXF94i7SGPFD MfcUGQ+YUmidQqjb051AOrdKKWYKdu1j+aKV1fa4MyLyiaJXU/ZqE9bSpl4/Bkxk SxEE3PXoduvZXz1lSdW12LAvjZT4ivVVf6/b9R2JF27+PFrXv51UhqUvXd9KNSF3 oChg1RpRVIqBPEBKsANqxhOlMu/cUgswc0c0zdWIcsrzvwzaIESo2hqOr/RKk+Dy A+AKp5auDhG8ttZ/Z+F4dGdIzzQHghhVmjpHah/JvrjOvXtaXXtOTgYI1iZCB1A6 HMNNCZx8oOqxzSw8NX34Y5aQdc00ktvvwSn6U1IJfhTsyF6Uk1zS7tw1JuqaeuKL odTvZcerrs6iJVo9KlCKhwRfKHmxhdQlcy/jajvr35nuzSWKYrtQ5Bsfe/YWOjaX eEwqDT4TWjBiVLkCcDaIQpQ7ZEvYTNkmuiHlhrwE/z23Onvg0f1duxULvRzRQaAK oMUQBTqOA2qOYQUjH6JcFGpcxOBNhUMptlIR4JrnH91Wp+8MDfOUk2C93AuCr/5F H8z6uto0ef2jPAxsYrrKhh2BgyIEFWLzAFHSId55r2feOj4AVQ0Q4s11EdvmNBE9 oiGioV3DeGL/P/d6YAzNbhiFzKHyqUCBrzkqZ5M9j+kTzfFBk469Fu5rvUB1GQ0L svS/WcVa6h8e2dnyl39f =dMjY -----END PGP SIGNATURE----- --Apple-Mail=_61D17367-FDFB-42A5-9733-FC718891CD84-- From nobody Fri Sep 15 08:12: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 3202A1321A1; Fri, 15 Sep 2017 08:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=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 VS5qgj49aA7E; Fri, 15 Sep 2017 08:11:59 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0868D132153; Fri, 15 Sep 2017 08:11:59 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s132so2348189qke.7; Fri, 15 Sep 2017 08:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=foWiEC4K+FcO5beRCE8aBDdRD65KVXzQszhOBy2Ozns=; b=C1deTqXpg6jzjI51GGTJZfnVMNjWpNUxo4J/1lqoGx1BZqYpRKKXS3CpDQKV7rJ95E R42KV3c3SJqtbCY/Pt10ZG2V1wyg9bZ2b6sDquFszE2QEv9RDa6cATYdxFC01H5urFBJ bt3QfbEDIrTeBjGraL7wFdT1+c6D5mm1KlLXdP813Ecv1FhvOyBgkQvQ9rzki4Uy32xc KP/4FgxILSQJfFMgMUldmok9OLseOCoE9V31l6rrUvTairBWJ6k59yrurwXERUiyIqxp EzkyeV6lnM1boQXIxJ7vByRgrPGZ0CHvLqF/+LGDpNFqJcaqIY6FPt9BRVtLRReDa4Y8 +Ppw== 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=foWiEC4K+FcO5beRCE8aBDdRD65KVXzQszhOBy2Ozns=; b=DmNyRt9pdNHFDw5TYDMhhxw47Vuom/ckke9c2NZSjPuw/Gjey3pkOsAuPhMu6YdUGT +fGFVKiba34km2hFdBhzu8xYPeDNWU2jzCbkbYOWIAOeN6aIVBoSQ056BIYnpMsIHZVS 5wdpP+ePOjCXSe4C5wd97rRhQCRWeHn4ljbDpkg/Ey1RZ2gVLP8k4kTaSsY1YJe3Dyns 4FmFPFKcmhjv7JthPzLbaoN8Ci/VfOtWQFbqwDWh40lwo5+GfBLgUdxiNE8ggdUlJTQ3 7J+iSbMp24yljyrs8ZBem5GnWncMzXwMdL0b0PePv4o11fim2E53F0meqw1A4HTe3wJd BkeQ== X-Gm-Message-State: AHPjjUjC+LjPMd72FtEqqejyXKuY19Z6lklux8ZuGVvm/d0us6/hJz76 Ct3Os0448XlIlIJVDJE= X-Google-Smtp-Source: AOwi7QCz/O9FbuwC1tUEab9al4SrKXLQCR0apFsGdAFE/UqtCDU0RXXbZ2Tm/5Gab90r7yCEgObYCw== X-Received: by 10.55.76.134 with SMTP id z128mr8281364qka.183.1505488317921; Fri, 15 Sep 2017 08:11:57 -0700 (PDT) Received: from ?IPv6:2600:380:5867:66a8:5a:3949:a2b9:b7cd? ([2600:380:5867:66a8:5a:3949:a2b9:b7cd]) by smtp.gmail.com with ESMTPSA id x55sm690991qth.91.2017.09.15.08.11.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 08:11:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F1237CC7-7804-4734-9F68-29B3690D8D13 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 15 Sep 2017 11:11:56 -0400 Cc: Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Transfer-Encoding: 7bit Message-Id: <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 15:12:01 -0000 --Apple-Mail-F1237CC7-7804-4734-9F68-29B3690D8D13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello, Sent from my iPhone > On Sep 15, 2017, at 10:04 AM, Spencer Dawkins at IETF wrote: >=20 > So, Kathleen's ballot thread, but since she and I share this curiosity ...= >=20 >> On Fri, Sep 15, 2017 at 6:01 AM, Loganaden Velvindron w= rote: >> On Wed, Sep 13, 2017 at 10:08 PM, Kathleen Moriarty >> wrote: >> > Kathleen Moriarty has entered the following ballot position for >> > draft-ietf-curdle-ssh-dh-group-exchange-05: Yes >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this= >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchang= e/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I do agree with Spencer, the text that is non-normative reads as if thi= s is >> > fully deprecating any recommendation below 2048, but then the normative= text >> > just says SHOULD. Is there a reason this is not MUST? I know deprecat= ing >> > things takes a long time. >>=20 >> Yes, it takes a long time, and also because of backward compatibility. >> We felt that "SHOULD" was sufficient at the time. Hmm, I'd like to push on this a bit more. First, do you still feel it's suf= ficient? Next, what's the explicit compatibility concern? If your just waiting on a k= ey rollover or something along those lines, it's fine for this RFC to draw a= hard line. Thanks, Kathleen=20 >=20 > That doesn't surprise me (speaking only for myself). >=20 > It might be helpful to add a sentence explaining that the SHOULD is for ba= ckward compatibility.=20 >=20 > That changes the incentives a bit - implementers have more incentive to im= plement a SHOULD if it's not a MUST *yet*, but when the community stops worr= ying about backward compatibility, it could be, and then other implementatio= ns won't interop with yours.=20 >=20 > And, for extra credit, that could happen suddenly, if someone posts a clev= er attack on 1024-bit keys that requires minimal computing resources and inc= ludes an implementation that anyone can pick up ... so everyone else stops a= ccepting shorter keys, like, today. >=20 > But do the right thing, of course. >=20 > Spencer --Apple-Mail-F1237CC7-7804-4734-9F68-29B3690D8D13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

Sent from my iPhone

On Sep 15, 2017, at 10:04 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= wrote:

So, Kat= hleen's ballot thread, but since she and I share this curiosity ...

On Fri, Sep 15, 2017 at 6:0= 1 AM, Loganaden Velvindron <logan@hackers.mu> wrote:
On Wed, Sep 1= 3, 2017 at 10:08 PM, Kathleen Moriarty
<Kathleen.Moriarty.ie= tf@gmail.com> wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-curdle-ssh-dh-group-exchange-05: Yes
>
> When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this=
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/ies= g/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
= > https://datatracker.ietf= .org/doc/draft-ietf-curdle-ssh-dh-group-exchange/
>
>
>
> -------------------------------------------------------------= ---------
> COMMENT:
> -------------------------------------------------------------= ---------
>
> I do agree with Spencer, the text that is non-normative reads as if thi= s is
> fully deprecating any recommendation below 2048, but then the normative= text
> just says SHOULD.  Is there a reason this is not MUST?  I kno= w deprecating
> things takes a long time.

Yes, it takes a long time, and also because of backward compatib= ility.
We felt that "SHOULD" was sufficient at the time.

Hmm, I'd like to push on this a bit mo= re.  First, do you still feel it's sufficient?

Next,= what's the explicit compatibility concern?  If your just waiting on a k= ey rollover or something along those lines, it's fine for this RFC to draw a= hard line.

Thanks,
Kathleen 

That doesn't surprise me (speakin= g only for myself).

It might be helpful to add a se= ntence explaining that the SHOULD is for backward compatibility. 
=

That changes the incentives a bit - implementers have mo= re incentive to implement a SHOULD if it's not a MUST *yet*, but when the co= mmunity stops worrying about backward compatibility, it could be, and then o= ther implementations won't interop with yours. 

And, for extra credit, that could happen suddenly, if someone posts a clev= er attack on 1024-bit keys that requires minimal computing resources and inc= ludes an implementation that anyone can pick up ... so everyone else stops a= ccepting shorter keys, like, today.

But do the righ= t thing, of course.

Spencer
=
= --Apple-Mail-F1237CC7-7804-4734-9F68-29B3690D8D13-- From nobody Fri Sep 15 08:16: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 A2265133011; Fri, 15 Sep 2017 08:16:11 -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_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 txr6btqcFobI; Fri, 15 Sep 2017 08:16:10 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 78559132153; Fri, 15 Sep 2017 08:16:10 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8FF91O8008611; Fri, 15 Sep 2017 16:16:05 +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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MdMeCmFdz1oTffrVrDNbzSACOisK6QN2Ev0DicN43M4=; b=Zu7eY1nNrlA3AWGpgFG0htYClRsLJpdaVdoGJfzDabe6M2iAt6HVupSmVpav5OdY/aDV Cm2TWkkg/hhx8zO8zCiJUmq403rlZQrN+WmKpyLmkGAghJQTPNsLamXjJlHQ5AhrjJe2 ExFKq2dCUsF7MxRmwCpbqltugCSNdfXJqQ8ZUg4oh0D7D/AVO2uBnsTGNiN6p8ZHi9RD GlfK/RUIrU0IMA80VWToDscrj36AYIbltiIf5V1s/IGoByZfWAfuJpmZYuNQQ8/iuzxT UHKOQF3jBz9E0Bix62I2kOc6X7T8bohZQZbQyKXybLWSSb9Zi4Xnw5cDP3Jj4IsjwiSX BA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2d0gv0g96w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 16:16:04 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8FF5xbR031173; Fri, 15 Sep 2017 11:16:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqkyu9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 11:16:01 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 10:16:00 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 10:16:00 -0500 From: "Salz, Rich" To: Kathleen Moriarty , "Spencer Dawkins at IETF" CC: Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Thread-Topic: Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) Thread-Index: AQHTLLtaStH0N4x45ECDj/E/tj4A4aK2Hl4AgAAzGYCAABLUAP//vhOA Date: Fri, 15 Sep 2017 15:15:59 +0000 Message-ID: References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> In-Reply-To: <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_06:, , 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-1707230000 definitions=main-1709150220 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_06:, , 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-1707230000 definitions=main-1709150220 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 15:16:12 -0000 4p6iIEhtbSwgSSdkIGxpa2UgdG8gcHVzaCBvbiB0aGlzIGEgYml0IG1vcmUuIMKgRmlyc3QsIGRv IHlvdSBzdGlsbCBmZWVsIGl0J3Mgc3VmZmljaWVudD8gDQoNClRoZSBXRyB3YXMgY29tZm9ydGFi bGUgd2l0aCBhIFNIT1VMRCBmb3Igbm93LiAgTVVTVCB3YXMgZnVydGhlciB0aGFuIG1vc3QgcGVv cGxlIHdhbnRlZCB0byBnby4NCg0K4p6iIE5leHQsIHdoYXQncyB0aGUgZXhwbGljaXQgY29tcGF0 aWJpbGl0eSBjb25jZXJuPyDCoElmIHlvdXIganVzdCB3YWl0aW5nIG9uIGEga2V5IHJvbGxvdmVy IG9yIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBsaW5lcywgaXQncyBmaW5lIGZvciB0aGlzIFJGQyB0 byBkcmF3IGEgaGFyZCBsaW5lLg0KDQpJIGJlbGlldmUgdGhlIGNvbmNlcm4gaXMgYWJvdXQgdXBn cmFkaW5nIHRoZSBkZXBsb3llZCBiYXNlLg0KDQoNCg== From nobody Fri Sep 15 09:18: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 AE19013352D; Fri, 15 Sep 2017 09:18:08 -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 FHf6rVC1RqwB; Fri, 15 Sep 2017 09:18:07 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 441561335D1; Fri, 15 Sep 2017 09:18:07 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id o52so2599442qtc.9; Fri, 15 Sep 2017 09:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XXixmafDrkXhK7Ea2pLYy/hprGZ0BETvDg0rA9oovDU=; b=BeNJiAxsDzZnA4K55i4+qkmzrzXCsjiMDTkTEJ5+4Oh2sx3a0lsPWCvzMmZ4j3Iz+W KHByTA5mED/EA/uqKiGtR+ufxQCdHDmEYdv6W9sdBZRnnGMUBj31AIIOwReOBG0F9OYS JIz3c3CtrM2gJSxV1wK2yL2RSsffYVuKnr0fOv/SmiGXbtDlq4zzzW5+RXHi0/h6+RBe hrNxHrC02QzO1+UR1u2XoaWEwdJJtWKMcjmEXtsy6BUktjK4vOcsJrpdRiqfqXW5HQUA T+RkienZDAKwssRTbjQbVaBln1QyYpxJ8WMOpsI+V14VoSNAjTPq8AnZv1loYmdsUeEj naqg== 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=XXixmafDrkXhK7Ea2pLYy/hprGZ0BETvDg0rA9oovDU=; b=V7oeoLXSJwqUaCCZBg8mzwTWW+cTc6hbgwwzFG9LMqtNVJfRMxxj7wdH8rv0tJLCFv M7b/Jei1fBP/DxR5q1BdOcHgBw6Avo8ldM7m/pVjCEI2FlDZbjSKtlB3CYa6qUoR+z74 rPQe1IJIblySfEh+I5AFtJWFcGWQiueqrIq2UkUJOZxFhwu2cUSWQ5GLe1rwBLaVx7c9 26ITQyzhe1m7zqSvL8I5RggA+ayJu9NoJs6+pdkaSaMPqzpmPR/nYQ0qTVtb20AKO9vv 8QdVyMJcq/l77a3HWl+F3vlYpIjFyPr/OmWCbJOE5NVpWkFjChg6JcxjMiNHwI5j3XEf mLyA== X-Gm-Message-State: AHPjjUizK3rc9QvdTxBdRvQlNX0Z1HNipMsqJXhcRxwhI/5+E5i/Yb2R t2sDr9AeEplfpzejRkc= X-Google-Smtp-Source: AOwi7QB7MhoAXu9GddRlYq7bwmRu65xsd5ssfvhWo6PTIN4lry0KxhGPF2CqUVgurPXywVw/Lguhgg== X-Received: by 10.200.44.167 with SMTP id 36mr26741634qtw.285.1505492286044; Fri, 15 Sep 2017 09:18:06 -0700 (PDT) Received: from ?IPv6:2600:380:5867:66a8:5a:3949:a2b9:b7cd? ([2600:380:5867:66a8:5a:3949:a2b9:b7cd]) by smtp.gmail.com with ESMTPSA id m93sm751255qte.72.2017.09.15.09.18.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 09:18:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 15 Sep 2017 12:18:04 -0400 Cc: Spencer Dawkins at IETF , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Transfer-Encoding: quoted-printable Message-Id: References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> To: "Salz, Rich" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 16:18:08 -0000 Sent from my iPhone > On Sep 15, 2017, at 11:15 AM, Salz, Rich wrote: >=20 > =E2=9E=A2 Hmm, I'd like to push on this a bit more. First, do you still f= eel it's sufficient?=20 >=20 > The WG was comfortable with a SHOULD for now. MUST was further than most p= eople wanted to go. >=20 > =E2=9E=A2 Next, what's the explicit compatibility concern? If your just w= aiting on a key rollover or something along those lines, it's fine for this R= FC to draw a hard line. >=20 > I believe the concern is about upgrading the deployed base. Ok, so why can't that just be done the next time the deployed base is ready?= Is there a reason why the deployed base needs to be compliant with this RFC= ? Or will making 2048 a MUST help to drive the change? Thank you, Kathleen=20 >=20 >=20 From nobody Fri Sep 15 09:28: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 44FF413304C; Fri, 15 Sep 2017 09:28: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, 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 09B4VbGGYlFc; Fri, 15 Sep 2017 09:28:50 -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 0312213301E; Fri, 15 Sep 2017 09:28:49 -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 v8FGRUjt022233; Fri, 15 Sep 2017 17:28:46 +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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=m7gGXDn/nWhcOYMpeKbglsiHOAU0HwkPspKhYhtNcrw=; b=ot/PgxZOO8rz9vUoKN1VqOqIk2aRxBRKztibp5O7l/1WIN6ac42vWbHF9xPq1i5BqR9D /cyGn/TfitZI0FydH3zLMlaMhCM/Wanbdxxj//YOqOa2bGAY0yUqusaQYWs1999rOrMI o0DzyVMDqEgeP5S0jehp1xs1ZBULAan4WeFkglKogadwvAclK1wuy1pnKPjnvD23/t6w jQBFv1v+rzGEP1idABDgfILTe9uNP5ushzoItyelrfxWD1FxvMcJhx3tPC/ZtfIQOWGa 6t1n0FbnrPEFdU6DwdR3pbYVSYuIB92r2jbmHkSzqv9cnp7RrEJ7CUGxrEY5Afzfu/pw KQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2d0gjc946m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 17:28:46 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8FGPmVa018696; Fri, 15 Sep 2017 12:28:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqm0wx7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 12:28:45 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 11:28:43 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 11:28:43 -0500 From: "Salz, Rich" To: Kathleen Moriarty CC: Spencer Dawkins at IETF , "Loganaden Velvindron" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Thread-Topic: Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) Thread-Index: AQHTLLtaStH0N4x45ECDj/E/tj4A4aK2Hl4AgAAzGYCAABLUAP//vhOAgABUZwD//7/qAA== Date: Fri, 15 Sep 2017 16:28:42 +0000 Message-ID: <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.200] Content-Type: text/plain; charset="utf-8" Content-ID: <9501EA6B651D0D4E8D882C374856E4F0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_06:, , 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-1707230000 definitions=main-1709150239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_06:, , 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-1707230000 definitions=main-1709150240 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 16:28:51 -0000 4p6iIE9rLCBzbyB3aHkgY2FuJ3QgdGhhdCBqdXN0IGJlIGRvbmUgdGhlIG5leHQgdGltZSB0aGUg ZGVwbG95ZWQgYmFzZSBpcyByZWFkeT8gIElzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgZGVwbG95 ZWQgYmFzZSBuZWVkcyB0byBiZSBjb21wbGlhbnQgd2l0aCB0aGlzIFJGQz8gIE9yIHdpbGwgbWFr aW5nIDIwNDggYSBNVVNUIGhlbHAgdG8gZHJpdmUgdGhlIGNoYW5nZT8NCiAgICANCg0KVGhhdOKA mXMgYW4gZXhjZWxsZW50IHF1ZXN0aW9uOyBJIHRoaW5rIERlbm5pcyBhbmQgb3RoZXIgYXV0aG9y cyBzaG91bGQgcmVwbHkg4pi6DQoNCg== From nobody Fri Sep 15 11:26: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 25A07132D54; Fri, 15 Sep 2017 11:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 R6b94a5x2Tov; Fri, 15 Sep 2017 11:26:07 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0090.outbound.protection.outlook.com [104.47.36.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2E9132713; Fri, 15 Sep 2017 11:26:06 -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=IwsVSIxNo/b+FUSUFrgQbvYQEY/qWrvxsLJLG1eZw9g=; b=kGh2Drkc5+tC64L++76QE619zL5EHfbCkBdY7A+Ft7NnkjocVqNx7QIZKXDKhtzjmQYm7yx/bt6zhhJHv1qKUY5WsQOS5frYcFPWkkCWQPNGfYn1ZyYEE+lrU22kOVRagov0UjfP+zY3CO/tcZodbgEBZ1LzbezYRINXCYmmQMM= Received: from SN1PR0501CA0040.namprd05.prod.outlook.com (10.163.126.178) by DM5PR05MB3609.namprd05.prod.outlook.com (10.174.242.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 18:26:05 +0000 Received: from DM3NAM05FT044.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::208) by SN1PR0501CA0040.outlook.office365.com (2a01:111:e400:52fe::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.77.5 via Frontend Transport; Fri, 15 Sep 2017 18:26:05 +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 DM3NAM05FT044.mail.protection.outlook.com (10.152.98.157) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Fri, 15 Sep 2017 18:26:04 +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, 15 Sep 2017 11:25: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 v8FIPQsZ003338; Fri, 15 Sep 2017 11:25: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 EA28B1141B; Fri, 15 Sep 2017 11:25:25 -0700 (PDT) To: "Salz, Rich" CC: Kathleen Moriarty , "Spencer Dawkins at IETF" , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault In-Reply-To: <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> Comments: In-reply-to: "Salz, Rich" message dated "Fri, 15 Sep 2017 16:28:42 -0000." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Sep 2017 11:25:25 -0700 Message-ID: <73822.1505499925@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)(376002)(39860400002)(346002)(2980300002)(189002)(199003)(97736004)(39060400002)(53936002)(6246003)(316002)(229853002)(50466002)(77096006)(6392003)(4326008)(7846003)(110136004)(6916009)(2950100002)(97876018)(189998001)(93886005)(69596002)(6266002)(55016002)(54906002)(7696004)(230783001)(23676002)(356003)(2810700001)(305945005)(5660300001)(478600001)(8936002)(53416004)(117636001)(76506005)(8746002)(81156014)(106466001)(68736007)(4743002)(7126002)(47776003)(50986999)(81166006)(2906002)(8676002)(54356999)(76176999)(86362001)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3609; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT044; 1:pjuOV0nti3rT5+CIjqpkhE/hMBAgHa2cDuEa1edv2rsSxzfYsARGQKAGEw4NNvpAyNYOne6PEnNzVOCC5OPOXU/TLEmjZxjY1V/tKgC8zSmQoI7q9996xSlfYFwlfsAA X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 46a5f8dc-1bc4-4348-d1ab-08d4fc673a1c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR05MB3609; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 3:cwQG+rbemWy5kA0K9Ugt6PCGcaWz/1T4xym8ECoHul2Z4DCqM7FhCg4HsdHnsaizPVVvyWq8dgxCQ1Qfx/W0HOEbKnW7SGrCMB9fSmfXsDemF6c7DmTbsyT4+wtguJwCCdijVl4ReI08uV0B/ruP2vhjhVwf0c59uOElvIMApgNcg0YgPJWMnQwVLRddUWNAltRwu6ocGZCb7rPQNLIK8/+A40ddY4QWyaiJNoq6Paiw4lUXiTTYQWkH1TzSzbLzWak7nj1wElJF5ORCyMb2rOqWX6MkD2fQupspFa5XQ3rQCI39KACO9Jxf1yt/f7CAWgWVChNxuKX8XX+USVsUFxDFmub9YqTZNcN1ZXHys0Q=; 25:Rni6MXtzIMLQ530mF5YMatqmvjevqW/7rj/GddWzqiit0ISol93VxJ+qs2rOR0dfTd1g8GFfH28q1uFFuwOYbqZVrQOPBB8GTIM4tWuh9xheJgnsf7JL3LtN04FdpKEhYYtkr6juGkLeRzBm8TPwzvehvALaarm/zx9J4nTKcHX1FvTXZPs74lb/7lTTe8jBtmKbI6oTW6s0o6fP2ha9KZjCt5/l7CgyYcjPu1McN4EE1EiBNz93MO2q7vbdx7+efmHseJKsanjArHA8H1g0WewHZLv3E4bxef9l0QODEV14JQoTqGTFhWZVXA3HLkK4dUL8kqwQ4IuMlhtnWoF50w== X-MS-TrafficTypeDiagnostic: DM5PR05MB3609: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 31:UA6p6HFLNi35Tt07zKjCH8fS8GoSMNxDa/550L/WXE6VTI3+5xL3guq4arLjSatWd2lTH/QWJYXYLa5STEN5hv+pcgsfeoXn3FPUeUvMzPscffLLGKcGRIfoNFsXjykYbOOR5yS2g3kbm+Mz9Ex/3VGO0KoEFfXJ5jtH6guEhLDLQZlTDyOLAuHdq324MXvk4uUHgHOw8BFbQ1hWZRgTmJk0LVTzcpJ5A94dixhd/y0=; 20:B0Hnnz64+zAqjAmHiWxgXSENuQJc9AHW8CXxtR71E16phUyT9F5wS1J9Td1CCNaqGbb4Mgf4SOiJwHMkDGoGQO6ZmEEzjnPrRzWbIMxMyZUA+O9yGmyf+BIZ1DSNIj/BPTzAM3Ata7FVM9j3uV6BUujQG7F9/Ir+g9xWk+gAUidsnmFMQMXRkwrMt7jsnl7LaA/Caj5v5UJw8Gce4AD2L0CWhWhHlmoiFKA7XvyZIk8jR0DzrzPXoTNWyC7V6+2HNlLD8LQVjYrIvK2njnrsvMr6vEKZI0ySOi4CDaXfemZJ2HWXRzFvQIgvrOutBzgIhIQR3jR4CMBp5AE4T7NI+RXcBmbmOs0zd1hTEvt6onKYDBWWGUGgv8KlWPNffhJ1YvZMgcQQ4XE0UtyIxmATy5TGSW5Z6p1fBJEGzNGdFSEM/+Q0F4rXiD0v1yMJO2l78zlvuqVNch4OMvE8ro3apK3boj+SKHh3zmT4HsXnIAV1SyVnqtUfIZFPI9yrcFCM X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93003095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3609; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3609; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 4:LgqrBptHCvl5X0qlnc1yie7DL6hpPrHmcDLKxUV8VJUOs+5yVr5mOZwqIvY48kAh/boCbtu0rl+q+kzRpzcfFxOLQLavSGTtdOdEyAYumI5f919FOK9IssmB0Xr05xMNVlSSeRZITtqLImVY8NW3t97p9iQJaJKk7GZTpvsFNjCFJXdN1vUJSFICXGAQ8b3LI83tIBHUA/+FPtVeCcFnHJDIYGsWt90HY9Q6vZY+B0pZS+0f+RxpkNcZS36Mrw68 X-Forefront-PRVS: 0431F981D8 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA1TUIzNjA5OzIzOlZWUWVVa0NVUnZGZGVXaTl3dXNSaVRzdS8w?= =?utf-8?B?clRMZ1phdkZCZk84bGVxVUhWdHk0QUV3RERobFVZYXVndGdpeDlLNHR1bFA3?= =?utf-8?B?d3Q0OGhpOEp4RGFOL3FmbWl4ZGVyWXMwSHY3NlRHYTRpa1JwRHNNWUVOZm1l?= =?utf-8?B?Y2VKa01SaitxbksvemVVbUdJclMwUUl6L0dQSW51UitBVExNNVRKZmhPVE53?= =?utf-8?B?S2pab0VQb2FDNFlCZVdzczhUcm9xeURSRzBkRVFJTkdocDFiMVcvYWs2TXlp?= =?utf-8?B?TU1sUVRKQnQ2TnUvVUZYbXh1cjFwd3NDN1F6YnExMGlYb2JhY05PTGdaSDB2?= =?utf-8?B?RGtzUFl4SFhGTyswWFhGVDBLeHJVVUFJZVZDY1VLVFNTMzhDTC93ejNLN0kx?= =?utf-8?B?cm50cFl4L1VUd2dLdnlUb1pGemlCQTE2ZDRBOGs0TjZTcWY2Zk5TMmJJUzZ0?= =?utf-8?B?UUxkWlpCOW1zRGZWY1drRnJabHJQTUNZdGQyYWtCWUlGbHhMaC9BeWlHb2Fx?= =?utf-8?B?bjhRSThyMHYxL1lDcEFjT0gzNEhJaU1OUisrZjU2R0F4dFFmOGtHWXJyQjJy?= =?utf-8?B?SFNHK3BsZFlPclJRZ3V4MExFWlc0S2piVnFtQ0h5L01qbWxhd1lNMit4dEkr?= =?utf-8?B?a2czbFNTUUxHMCt3VnBFSTNQOTZXaGtIQTQxb244OXJjMU5aOGxRejlCZmZB?= =?utf-8?B?SXlVa2N1OWM4WC9Zc2tJck1vU2pKMytnSXYydlExcytHVkc5N081OU91QWo0?= =?utf-8?B?RlMyMXdWYTB6UVZ4dHhLaE42Ni9pVUduV2pCelJVNDI2eEJTdklsUDgzTW00?= =?utf-8?B?aEt4Mis1bmROZEdabldkVHpIblpkTUxBd3IwY1VaaHRidEx2RDRmcWNWaU1O?= =?utf-8?B?Y2ljYXJJRDZQcE5HSTRnZ0lNcDNDbC9ZWTl1SnlVODdSaXIxd0I5SnN2eEc1?= =?utf-8?B?aGptRmlWZEFhUjFCMExwWlEzNkhRL1ZBR0d3RTZoZUNwUU91eUxMSmhUTnh2?= =?utf-8?B?eERzTWVrSDlFNkxsZTIxT1lERytMc2VZdzlyYVkxREk5a0dCTVpWcG5QbFJD?= =?utf-8?B?R3lzR2U4L1JTUyt5TkNPMlhPbW1oUkI2NldDaVdLVDJLOFA0UGRKclcvakl5?= =?utf-8?B?M0lySnRUODNxZHNSZ3hxNzhUaG9VaUxMVktneGhudGowb000RFcyZEdNN1dY?= =?utf-8?B?MWVTb2VtM1BkTnIwdUJub04yTjM1aXZkVlo1dWpIeFdMVUdCeGczSkxPMDZy?= =?utf-8?B?cStnU2dQbmVKV0N5YnBpbnI4NVFuOWRteTJkN2J4TXh4eVFrNVlXMGU4Y0Rn?= =?utf-8?B?VHlJMFo3eXF4SGhpcGhuUGlZeDMzMXRTdEhqMHd4WHZ2S3FGOHFUN2VuYmow?= =?utf-8?B?d3pobTdEN3haZ0kvbFJ4dDI1dUkvM0xDUzhZQVNWQWRBTWpDb1RrcU9XaDBZ?= =?utf-8?B?NWtuTTQ4YloyR2IyeU82QUxsRjJOalJHM3plQ01PdEtrdjJSTWVXZzh4dTNx?= =?utf-8?B?WW9NbXhqWm9la3d1WE9yWXdvYXNsazhKaTNyZklWV1UxbVVEbVVYQkdGNUNj?= =?utf-8?B?UXk3ZTFMVjUzTFpiUUJXbTFiRlN3SVZDYW1zbGFTMXFldVVCU04yd3kvM0dI?= =?utf-8?B?Wm5IbmhsQlFhMWJma1pzYWtGZWJTY1kwQ2N5Skw4YmRMNWZWNUFkd0oxU0lD?= =?utf-8?B?YUJaNVEydTF0R2RRUXova25HN25lcHV1QkJuNUpMaU1GRzN4bys1ZjRFNnZt?= =?utf-8?B?QmhNcmN1dUlYQmdZUDRQQT09?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3609; 6:mOBjuE4Pvf1MmaWQSaCNG+S+xLgE2+YrSpbFektue4ETCItTMWbZOt/sOfOCzwJjpPCn7sUoW7OeNLk/4dduoeURdsiY7gmM+Bs2WwePCGkbvlW4UE/8kNABIOwnCnjovd5P6cjid00TnZOZ9HYirOoMxex4hJnYSkuWsg97mdP4PY9b0WHa/X3h/wDyuxUAS7xcwRb4vwG8dvq+OO0Mwid1yCd5TRNqhjTceLVJFUZwoi8UgMtYIlj8rIQLpBkjTx/xHKwJiafTZftGj6qbLqkcli5bavpAbAzVCMpLZ53/gTl8EGLZATV7PG6YlDxmG+YHTTmDznk01TrgmmBb4w==; 5:raeoyK9tJbhqRr3ZzAtWYxnsfclvvKRGwbfx9r5AfEz5IkfUnSAQieAtTsLorXYxK3uH3hw680dou1vBfqXVPHmc/LsXEELojs3WnUx9XA2LPKKVlkTwif8cE4bGtpKN6z6E+z7N4lEJ0KG+pFk8Yw==; 24:QGyNJ80gSziG99HFEi6fczP6iKHpZTiFIH0pRAB8dc8HbFWUTDaH+TgrpODjZ0G7vKBXmbYiJgtdEMsghENgs1sRZFZLPaSydtj1/2+u2GM=; 7:1nl7z7kR2ZxalT/n2iCjcoOAkSGM5ghNThi8edW0KgxY0lQGT1QPQQdnHXsdI0bJ0BJgQlJL6iGPV2l7J4vI2BZrh9vIPSJd+YXZvpUC0aQbnZzIMwGpEPCQmxX2h0GRE0rDhf/C9pJMMnFj5VVJPglQRjwCROjmzRQ1ubSUwlSt+3m4eGoNoXs4BrfZ2U/1uUQjLHrxN62OJesLm6TGHGqaNoqU8s3onnmnR+dnwMk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 18:26:04.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: DM5PR05MB3609 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 18:26:09 -0000 Salz, Rich writes: > =E2=9E=A2 Ok, so why can't that just be done the next time the deployed b= ase > > is ready? Is there a reason why the deployed base needs to be > > compliant with this RFC? Or will making 2048 a MUST help to drive the > > change? >=20 > That=E2=80=99s an excellent question; I think Dennis and other authors sh= ould > reply =E2=98=BA My biggest change for the core SSH protocol is that governmental agencies are mandating compliance to the standards if SSH is to be used in a product. By updating the standards from a SHOULD to a MUST without consideration for a large installed base of embedded equipment, we may find that many products are being excluded from being used when the 'standard' they define is bumped. For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the word "MUST" for the current 1024 bit value. So, in this case, just updating a SHOULD from a SHOULD seems reasonable to me. If it were a MUST, then I would probably advocate for SHOULD NOT as the step down. For example, I would have no objection to adding text which says that the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than 2048. fwiw: I also suspect that 2048 will not survive more than another couple of years and would not mind saying that "n SHOULD be 3072 or greater". I do not believe that view is accepted by everyone, so 2048 bits is what is in place for now. I worry more about more of core SSH compliance changes. For example, diffie-hellman-group1-sha1 which is in the original SSH RFCs as a MUST implement is too weak. My draft moves it from a MUST implement from the SSH core standards to a SHOULD NOT. I stopped short of going to a MUST NOT as I believe there needs to be a transition period for the implementations out there to become compliant. I say this because I have observed some standards (NIAP an Common Criteria) currently want exact complaince to the standand RFCs they list. For a large embedded installed base, it will likely take a long time for those boxes to be updated (if they even can be updated in all cases). Is SHOULD NOT stronger than SHOULD? It may not be, but somehow it feels stronger... The above is my personal opinion and may not represent that of the company with which I am affiliated. -- Mark From nobody Fri Sep 15 11:59: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 CC80D1326FE; Fri, 15 Sep 2017 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=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 yeA1385FSwd8; Fri, 15 Sep 2017 11:59:00 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF8C132D7B; Fri, 15 Sep 2017 11:59:00 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v66so2010697pgb.5; Fri, 15 Sep 2017 11:59:00 -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=jb0s/S561WSRETL74ZI/WIszP7Zdg0as+DO4tU0/JuE=; b=ckS4jPg+ei8sTidyFcfX9ObiSS+hFSakFdq9pCGTvNRkPsd+RSCkBDOV7lZ4wwTkDy 2xZj6RgYVxF0rgSSpklwLEXw1mP8M+SICEYijSR3cUTSZLJKgdOXqS59RGrzkWQd+tpn SYJY3eOd/g+/UmqM8O8dJUV27p4jcKCAvBt8VJB4uMSlfV+vE4WuzgUdMcQU75GNtkpZ qvBFvsK1cn0aQAiaC4nAVcspSkDiJ9xzE1kJSVyY0r+bwzQ7LVTxVvSEZHdkL0cW6PNc 2P4hR2KYspRx/TcTz81v+GdQqp6+Ane4etp8/AwDecz/mPJsgAxtp+QPlSBDinf+O+Vd IwOQ== 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=jb0s/S561WSRETL74ZI/WIszP7Zdg0as+DO4tU0/JuE=; b=Bas4NBx7vhgQBOus3X2cz3QvTfqP0byjxhfraLOBmduYPyk35jKVwUtACFT2EnOljD kldCriUY2jU0JW1+9qf5RwWdiBqJZNAPzj0cQn7zzdtK6V1UNv+Xd3iK9bWAdMqsRTlH f+O7IbpIw/VRWX+B35QUUaeecD2ypxdAMcU+WaXnd1O4FtoIl/Ughl51Oz/mhgUNlaC3 eC2Fd9N77juvTIGWMmoXFXsJuJCh1CQQ6I1KhB588C0wKtP2t2tSBc3ZDm/1AIsAafEi qP+BuKIxhBsdKyzqEuIGtSr7oWiY/qnVJpcz39KgmCL0kMkSCISgY7tb31yiDQspmlfA /Wcw== X-Gm-Message-State: AHPjjUiTP9+avThlL8RCGAp4zgjGTdlgMQADZ4wemCumTwntOMtXDszV 3b1C9G3lWFDDY/eGl0/jju+cMPtqMvy4Ulpc6Lk= X-Google-Smtp-Source: ADKCNb4zyOvpmcOxjnXd1+3UM8w491sapo08nDbEghqdLggSr4TcOZhWW5LLFV44kTJPPFzYyqevQfJD1635egd/ZIc= X-Received: by 10.98.68.206 with SMTP id m75mr25964964pfi.163.1505501939660; Fri, 15 Sep 2017 11:58:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Fri, 15 Sep 2017 11:58:19 -0700 (PDT) In-Reply-To: <73822.1505499925@eng-mail01.juniper.net> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> <73822.1505499925@eng-mail01.juniper.net> From: Kathleen Moriarty Date: Fri, 15 Sep 2017 14:58:19 -0400 Message-ID: To: "Mark D. Baushke" Cc: "Salz, Rich" , Spencer Dawkins at IETF , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 18:59:02 -0000 Mark, Thanks for your detailed response, I appreciate it. Inline. On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke wrote: > Salz, Rich writes: > >> =E2=9E=A2 Ok, so why can't that just be done the next time the deployed = base >> > is ready? Is there a reason why the deployed base needs to be >> > compliant with this RFC? Or will making 2048 a MUST help to drive the >> > change? >> >> That=E2=80=99s an excellent question; I think Dennis and other authors s= hould >> reply =E2=98=BA > > My biggest change for the core SSH protocol is that governmental > agencies are mandating compliance to the standards if SSH is to be used > in a product. By updating the standards from a SHOULD to a MUST without > consideration for a large installed base of embedded equipment, we may > find that many products are being excluded from being used when the > 'standard' they define is bumped. Embedded equipment is a tough problem. So for this, your worried about new purchases. Sales should go way down with the SHOULD at this point and I wouldn't let an organization I managed chose a product that didn't support the minimum recommendation at this point, so it is really an issue if there is no competitor and the only choice doesn't meet the minimum SHOULD. If it's already purchased, then we are talking an audit issue and possibly not having funds to buy some million dollar piece of equipment that happens to support less than 2048. Hmm, in the past, I've done thing to mitigate threats like isolating such hosts when the threat warranted measures. I see your point, I'm just trying to walk through real instances of issues to make sure we are considering options well. > > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the > word "MUST" for the current 1024 bit value. So, in this case, just > updating a SHOULD from a SHOULD seems reasonable to me. If it were a > MUST, then I would probably advocate for SHOULD NOT as the step down. > > For example, I would have no objection to adding text which says that > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than > 2048. > > fwiw: I also suspect that 2048 will not survive more than another couple > of years and would not mind saying that "n SHOULD be 3072 or greater". I > do not believe that view is accepted by everyone, so 2048 bits is what > is in place for now. Hmm, than it would be good to make a note of this so those who are replacing embedded equipment make the leap to a higher value than 2048. This can be in the non normative text. > > I worry more about more of core SSH compliance changes. > > For example, diffie-hellman-group1-sha1 which is in the original SSH > RFCs as a MUST implement is too weak. My draft moves it from a MUST > implement from the SSH core standards to a SHOULD NOT. I stopped short > of going to a MUST NOT as I believe there needs to be a transition > period for the implementations out there to become compliant. I say this > because I have observed some standards (NIAP an Common Criteria) > currently want exact complaince to the standand RFCs they list. For a > large embedded installed base, it will likely take a long time for those > boxes to be updated (if they even can be updated in all cases). > > Is SHOULD NOT stronger than SHOULD? It may not be, but somehow it feels > stronger... It's technically not, but I see what you are saying. There are a few published RFCs (I think some CMS RFCs) that took on a notion of SHOULD - and SHOULD + as well as MUST + MUST -. I see the JOSE algorithms RFC also uses recommended + and recommended -. The minus shows that although this is kinda okay now, it really isn't recommended and shouldn't be in new products. Do you think that approach could help to allow some flexibility, but also show 1024 is on it's way out the door and 2048 will follow soon? Thanks, Kathleen > > The above is my personal opinion and may not represent that of the > company with which I am affiliated. > > -- Mark --=20 Best regards, Kathleen From nobody Fri Sep 15 12:45:36 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8123C133074; Fri, 15 Sep 2017 12:45:34 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150550473449.4821.11100578895844809294@ietfa.amsl.com> Date: Fri, 15 Sep 2017 12:45:34 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 19:45:34 -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 WG 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-09.txt Pages : 7 Date : 2017-09-15 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 including an errata fix for checking the Peer's DH Public Key. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 15 13:00: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 9EC95133207; Fri, 15 Sep 2017 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 It26yLAvEF5k; Fri, 15 Sep 2017 13:00:03 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E711341E8; Fri, 15 Sep 2017 13:00:02 -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=H55IjbeB8FtSq6UFU//EwMyehC5Jm/HqwJbowRPSWhQ=; b=ja2jT/YsVRChGtaflKZv8Xq13YS3vnod1VHN4PTRRoX1oDRXfeS5O/U1qQWr6xbG67dEbYSwpzDeaIIyvvWY9NbjiomF9zB6rBh5HGg9GCwmPmdO9h6Xnd079AVy/+dxiQmh8s7OPQ30TNRigDmdVZQvczsO/EesJG2Q1MZGYcw= Received: from SN4PR0501CA0019.namprd05.prod.outlook.com (10.167.112.32) by SN1PR0501MB2079.namprd05.prod.outlook.com (10.163.227.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 15 Sep 2017 19:59:59 +0000 Received: from DM3NAM05FT025.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::209) by SN4PR0501CA0019.outlook.office365.com (2603:10b6:803:40::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5 via Frontend Transport; Fri, 15 Sep 2017 19:59:59 +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 DM3NAM05FT025.mail.protection.outlook.com (10.152.98.135) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Fri, 15 Sep 2017 19:59:58 +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, 15 Sep 2017 12:59: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 v8FJxG09002541; Fri, 15 Sep 2017 12:59: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 7B5201149C; Fri, 15 Sep 2017 12:59:16 -0700 (PDT) To: Kathleen Moriarty CC: "Salz, Rich" , Spencer Dawkins at IETF , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault In-Reply-To: References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> <73822.1505499925@eng-mail01.juniper.net> Comments: In-reply-to: Kathleen Moriarty message dated "Fri, 15 Sep 2017 14:58:19 -0400." From: "Mark D. Baushke" Date: Fri, 15 Sep 2017 12:59:15 -0700 Message-ID: <33805.1505505555@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)(346002)(376002)(2980300002)(24454002)(199003)(377454003)(189002)(97736004)(7696004)(97876018)(8936002)(356003)(117636001)(8676002)(305945005)(81156014)(81166006)(2906002)(2810700001)(5660300001)(7126002)(230783001)(50986999)(229853002)(77096006)(189998001)(7846003)(48376002)(16586007)(4743002)(6392003)(316002)(54356999)(76176999)(53546010)(93886005)(68736007)(69596002)(110136004)(6266002)(6246003)(53416004)(54906002)(76506005)(50466002)(53936002)(55016002)(5003940100001)(39060400002)(478600001)(105596002)(106466001)(4326008)(47776003)(6916009)(2950100002)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2079; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT025; 1:2I02TslKSCqTnzTZxefs98qPFbix5E9/bdlSxyOWig8czuhnG43BevmLvH9DBxcoDEwGB/ncSVYiGDC1HPNpZWUUq/GIFjCqDqOANWnQ6mfPuQd79a/VvkQ6KidQ/gE+ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dc8bc597-be88-4293-bfca-08d4fc74584a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0501MB2079; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 3:sIMJ3mxj4Fm7CAZovgCGAETrraW2AhEUFvD2Q2XfYHnAD+yJwP1uP9zhnXpupcbF/ITb53m8D1cLqmygj+En7IOkK4/6vcRoEFbyBsCIm0YrWqDgsVf/+5fXzyI1GIgmxU9JxeSeqHr8le897Cwm0RwgRGFupMY2mQpIHBAGIIJCYX6bd7fjLyse6pklZgZP8Iha+IalAFwKJW99MAh1FTw043UaEu91aqzTGJH/a4vOr/Seikqb8KxsSXl+K8bynxM5ubflUVYDsv21UnA7W9QMgAP8D1559ZBSzPotEivds7GxKzzC8rT7SgdNw59CVh/YFoEyggdH/WILA31uya9nGXCPXu8Ka0EM21Gzcm0=; 25:ufV3TTlfOeZc8TYRXqt3S0KsgeZr4CWzbjMAnNUmhgCB7z5QULjNZSsMVZePI1HqHxpZeMOEFhVXS6QHrreRwoC/0b2ik6gkzjdxwlT1kDS10ZN66rVOOYqeQu6zU9QtBUtO7PxoJs4jsiflJmAo4w4bYThVyZHGdP0rytADZNphxEPfHxwg0djw10rhu3W6njm9yOFGnmJ2W6lCHt5Vah12+/w56aKgrldJ90kFfM6l5DnDhu2J1PSMEPTvCiTfuMsnIuWlXs4bvd2srunflwYCJDwtEknfP+Jiuf67QUXCV0tZlBrcPjy+4hbDY1SPge89Vi6WdFPdYZTQaXqySQ== X-MS-TrafficTypeDiagnostic: SN1PR0501MB2079: X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 31:Q6MsFlSQaFE4sHQbNAPnNGOvkPu3vt35Ji/+TK2+nWTO7Hbb2CWP4zroY88uveuq+FuPIYO9+UPIrpjO9I25q6Q7auyOeuAdhnwzxOCQQP5gTEh0z/rWlul6CM1iWBiKssQ72taXFb/XdwNcs47Cnp3Ygcda1k2vlhFwXl+KfL83VD66rtoEN2hICuk7TSHqum74dvEwHqYaRiR363FObnzQmXIXqu/HJy/gUWlDQZw=; 20:232BwkJM9Bc9UucklDpycM65iJz35+GYVd0AkfO/ytMHlQq34NlDjwzSU6DupFlFBe/fDI6plVOCRF2RV/E5NYBJDrBOwGiKEAMV7H/K1uUJNAvUrrCm7zdrmjNGPdVfpnxjT7DvSZI08SndWPP7aGhxxrMYAOwDR0l1YKmkVZWqcX3FzQZ4P2RZBnP6sDc4NwGUFt9vuO0CvU0pfYfhiatmGkwRSV7tzakHeSGcL/naIc6GXT7Adg2Y65Lz2tuJT5QhxQZ6NWi1BVkqdHpFjHNUjBCgu+fnjveE3s25PWZuwyey6QUWdUKO4MykSJGvLTtWuwA1j/atM+Tl2Sc+zIgpzG7woYHT0YtHg5a99S9d0i/K/3Sdtm9REnRjB5dcunTfUA3GMnltt8AB19x/AR5QFA0KtuNLyDxxgXK277vwNlnsQ8iTmuZ9zE2mI6oAR/xWPdbbx14DHGVak1FE21xfFjEp82RZvF/nfpEpKVX8ImPlWA7rn6N3zRN6D1TD X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(138986009662008); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2079; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2079; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 4:oZXMaQ8j/Z2sUpJVpt2sAO0JmuF6UfnoDNnpS+nkcgWxWkNs37nRzUx14DcroYvk7EiLGCUiqCrtV+XbEiP7JMpp16PGBU4jSUqQBGiO8C02W/GIG8KihYPcnCwo+wXJWRYyoJCgBDlj8S6Q6VviH1dgLl41CJNIfT0CL0XF0ENUVTXKcBJEh/X/t/vt2PjZ1iiBOpRJPGrQijUsGzGZf2aVnMkE5SVAuXlLKSFYD4dOjypVKMRdddiliyRYGubB7corJH8yz0HTX9MYMtpsBJ1gdVauqtx/g1nzgv8k0r3ZS17iZnZxReDUs9C1tn/sMMWvi5GYeiI6D+KDIP8Zyg== X-Forefront-PRVS: 0431F981D8 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2079; 23:NazfxYMugqYYQpnu104ZcDrCqKoE0UCovxxNH4F?= =?us-ascii?Q?WmGmdEAOdo+BfztZ4s2WAfUlWQMNZkiDBUn4XyMo3q83atT2eYVAnM8dfT2l?= =?us-ascii?Q?Af6WNlSIrVMDV7kNJx8gmUsaKTxRt5D/0+NUe0ZVbh2mRD4qbnjgM9mpIPZ/?= =?us-ascii?Q?2PjU4FKAUCauxpNIMvsY46BDZJOOKBmGKg9icQAhuK0qRrzu0ZCUuzyjx1lA?= =?us-ascii?Q?wa4ZFpJAqgJgxN1dQ8SBng1lzzE7B3kJ2XjfmOMdEQjS5BUtHEev35hgtjvX?= =?us-ascii?Q?e+PjfAdc5HU3DZYkhcwt4PpdEjWjNH31NSwOugdOLa7I8YEGkbC9WfUYixB+?= =?us-ascii?Q?gYFhdXqFzmRjGMW9drE4M04EhkKTC1XNl0ZKviIH2O1LAyiVLcSDFwIue9qO?= =?us-ascii?Q?y9KDAUtDXtWZ76sTABbjLtTeJo0y8qLhflW7+4lsYzQcwVkEqTU0jRSdSwF1?= =?us-ascii?Q?DmJmGlVKa1Fv1A8QzKeEcjH5WlLGQB1GK9OTL6+JFBcMd7KswSg9qpA7kG7u?= =?us-ascii?Q?VbIcH75ynYVnLx9vUBJ8jrFPHlgkedsPM7kwCFp3BSoN2ms+DKR20sB1EMvr?= =?us-ascii?Q?ABnE3RXIajZtp/BBjWEydrGA/FbBplatrcXJnYs5C16Jvz/o9CkMvRsofgLC?= =?us-ascii?Q?rTEPtMKiiRyNRIau+VDaIK0OIvZnUKdV2lhvTt3/Wcv+Uei2BKpHZi+A3UqC?= =?us-ascii?Q?zQkCSQz7TrjlmOcBZHgUW7H6Uax2q1aYswaSNbbNEDJdt334zBz5yBgDmKd/?= =?us-ascii?Q?LSey3XECEDMNONk06zALO4ruwc1Lr/EE2flCIfNor7rOuPirH+LTgH7uE90y?= =?us-ascii?Q?K7P4lqmiFU8kmbiT/0GTQTtdNscTV4blNhPBsknYozihJ7Cd1B+hC8htw4Jm?= =?us-ascii?Q?I2883PKC0N8Jr7dImUxLtPBJBlYa1kjkhH+4jDzhOew30u0A6ewcsZ71+y8y?= =?us-ascii?Q?CYWbzpGPk1slshDmTINQZlxASDpHcPWrBTICfYrOj1cCzymxdsOl7Y0qA4my?= =?us-ascii?Q?nnA3ghMULwJm28xpWlBwBDb3+fN98qoUZq9TDlmllWfvVw7JShVLWj8hRufD?= =?us-ascii?Q?3ZqLBn9upNTSD61z4RFIvaNBOzf9kMd5vTb5331LUO8GRDHNLNzV5pXC5VCi?= =?us-ascii?Q?ciE1LuJLCvjqkhR+xoTlTK+087O5tuCchmFfMO02WyK+a0aqeopzzbPF11uD?= =?us-ascii?Q?0qmUAl8pqYwJOhdGavH9FtG/e9hzj+6kE3yUZQKWp7zoBH0Sl4NoVM4c0hNB?= =?us-ascii?Q?0tFBSXTswqlGR6e1++Pld7r9uWpIWLtBXNOqfjgsdAnkk8WSPAUQY5Dc8Wvz?= =?us-ascii?Q?EOneTcWPRmfHTSrWFt6N5oZbbf/9aNe3o11cdaz2YZh5IU35RTUoa2Kpv5Ev?= =?us-ascii?Q?H93SK+sN1/zpjxyZIeR/o9fw5rZq2QnRduls6nkRTNNQld6WS?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 6:FdDm3EsjqzkN5pLWyKIlP04DwIQ7ahl9AIaWMzy25ZE7nDVpqnMD5Xf4XyzgihOmO8cLmzVPVGIWpPCg0KGdjONQbD2KPyJDTLUSB7VFm1l6mmZ37mQryKMHJdrrZKaZedW1XotNzmiUndjeKjU4bvI/NyML++Iu1UERHeKHMKilOZgSmq0V+2XPP3Uz3I6zAZ9Lh1fPIcEUaprxIwOSWGtRExUG+zF8XnptnFgdzNybicZ6406eQMzMlQaIoMwo7q+wu9ceJp9QQVxu/h9RprwSjSijSJFNZp8CmkTRrnrheBfdPV7L59sEyagba1dvZy5VGS9dX/nsgcN+L19sSA==; 5:nEwYUpvnofi99aqoMgTO71T/c3SFw3b0mCvj+uIaNW//elgNR2BrkUqSRv3yly9J8VEwEwAxejaJrtDCcgGR8S4ZTLhMnUQR8GuhUGcqhN0KHmRTXvxNEnXwr7XS7PUF/4/pylOQCvfSPmOhdD3DZA==; 24:KvJko72iMCDz8nmWk1l8WOtQGAPd5sWdOX6c3t+tu19m2cb29dj1utkTSe4Hir3Qx8JFJ11kzyyXG4xHYM2klCdWfdQBeye76PtFzs4JEjU=; 7:Fq8WNlUPdxVcVwLKzcVaqnSFDMGGYgV2iGL6x88ZXfrX1FG/fmcaXfEf+Yii5YgamTbH2S9sE8XCGO5MjLiK6ZFLs/5PCDtYYWxvmDZlR77UDKRdFoSP9HlXgQ6AtCnAzUmyI19/Vu6ycvsvFl75jZrwBz8E6sHwGkVtgcmkbalTadNgdQ6juJIur45ZIFzIu6Igy3cQ7Zz4Yb9IHn3N4eFcEJ2x4wxKfElhN2j8ph4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 19:59:58.7844 (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: SN1PR0501MB2079 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 20:00:05 -0000 Kathleen Moriarty writes: > Mark, > > Thanks for your detailed response, I appreciate it. Inline. Trimmed response, likewise inline. > On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke wrote: > > Salz, Rich writes: > > > Embedded equipment is a tough problem. Yes. > So for this, your worried about new purchases. > If it's already purchased, then we are talking an audit issue and > possibly not having funds to buy some million dollar piece of > equipment that happens to support less than 2048. Well, one hopes that with a million dollar piece of equipment, there is a support cotract and a way to update the software in that box. I was more concerned with needing to sell software to manage thousands of very low price embedded devices and still be able to inter-operate between the management station and the devices. For example, a conformant implementation that MUST use 2048 bit keys, but needs to talk to a device only able to use 1024 bit keys has a problem. Likewise if the embedded devices only support diffie-hellman-group1-sha1 as they were two small and slow to manage with diffie-hellman-group14-sha1 when deployed as a read-only device. Does my management station get to talk to those old devices when MUST is present and exact conformance to the specification is mandated? > Hmm, in the past, I've done thing to mitigate threats like isolating > such hosts when the threat warranted measures. I see your point, I'm > just trying to walk through real instances of issues to make sure we > are considering options well. Yes, and I really appreciate that we are getting this into the archive. > > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the > > word "MUST" for the current 1024 bit value. So, in this case, just > > updating a SHOULD from a SHOULD seems reasonable to me. If it were a > > MUST, then I would probably advocate for SHOULD NOT as the step down. > > > > For example, I would have no objection to adding text which says that > > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than > > 2048. > > > > fwiw: I also suspect that 2048 will not survive more than another couple > > of years and would not mind saying that "n SHOULD be 3072 or greater". I > > do not believe that view is accepted by everyone, so 2048 bits is what > > is in place for now. > > Hmm, than it would be good to make a note of this so those who are > replacing embedded equipment make the leap to a higher value than > 2048. This can be in the non normative text. So, using words like 'desirable' rather than recommended or should? I guess that might be a way to approach it for this particular draft. I am less certain how to deal with the more general issue of algorithm deprecation in the security area. Guessing wrong can be very expensive. > There are a few published RFCs (I think some CMS RFCs) that took on a > notion of SHOULD - and SHOULD + as well as MUST + MUST -. I see the > JOSE algorithms RFC also uses recommended + and recommended -. The > minus shows that although this is kinda okay now, it really isn't > recommended and shouldn't be in new products. Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2 and eventually removed it due to comments not liking it. > Do you think that approach could help to allow some flexibility, but > also show 1024 is on it's way out the door and 2048 will follow soon? I do not think that moving to 'a min value of 2048 SHOULD+ be used' will do much to help this particular case. -- Mark From nobody Fri Sep 15 13:04: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 007E61331F5; Fri, 15 Sep 2017 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 3-ia6oXEdbZ8; Fri, 15 Sep 2017 13:04:45 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0111.outbound.protection.outlook.com [104.47.40.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED031329F9; Fri, 15 Sep 2017 13:04:44 -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=TwLTZ06uekH2NLFFaj+Q9U4fCYfQU82ejz3xIxGVlxQ=; b=ImOsILj/b15GJCthr0FwXl1cij7wXaLyMFglRDkixAJrGXSJX1DyYJtonx+lScRlTx8VK684unXzMhT0n/7XA/xN5nxtx2Yj6m8cqejTla3pSIFFM6BjeWd0K5hYaC678yGjFsuzcr0+BBuVpiqUsX81P6NXxHRhwvLudxp/CXc= Received: from SN4PR0501CA0120.namprd05.prod.outlook.com (10.167.128.37) by SN1PR0501MB2078.namprd05.prod.outlook.com (10.163.227.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 15 Sep 2017 20:04:43 +0000 Received: from BY2NAM05FT054.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by SN4PR0501CA0120.outlook.office365.com (2603:10b6:803:42::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5 via Frontend Transport; Fri, 15 Sep 2017 20:04:43 +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 BY2NAM05FT054.mail.protection.outlook.com (10.152.100.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Fri, 15 Sep 2017 20:04: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, 15 Sep 2017 13:04:41 -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 v8FK4eqH006272; Fri, 15 Sep 2017 13:04:41 -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 B3C4211554; Fri, 15 Sep 2017 13:04:35 -0700 (PDT) To: Alexey Melnikov CC: Adam Roach , The IESG , , Daniel Migault , , In-Reply-To: <1505468489.1399722.1107025704.592DA5B6@webmail.messagingengine.com> References: <150530317007.30493.16902496715822942927.idtracker@ietfa.amsl.com> <3253.1505310397@eng-mail01.juniper.net> <39647.1505413606@eng-mail01.juniper.net> <1505468489.1399722.1107025704.592DA5B6@webmail.messagingengine.com> Comments: In-reply-to: Alexey Melnikov message dated "Fri, 15 Sep 2017 10:41:29 +0100." From: "Mark D. Baushke" Date: Fri, 15 Sep 2017 13:04:35 -0700 Message-ID: <70007.1505505875@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)(376002)(346002)(39860400002)(2980300002)(199003)(189002)(8676002)(86362001)(6916009)(7696004)(2810700001)(2906002)(229853002)(47776003)(189998001)(8936002)(8666007)(81156014)(6392003)(81166006)(2950100002)(7846003)(68736007)(7126002)(69596002)(5003940100001)(16586007)(93886005)(5660300001)(77096006)(305945005)(356003)(6266002)(4743002)(76506005)(53936002)(53416004)(50986999)(54356999)(4326008)(6306002)(106466001)(105596002)(50466002)(76176999)(97876018)(117636001)(558084003)(230783001)(48376002)(55016002)(54906002)(97736004)(110136004)(6246003)(316002)(966005)(478600001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2078; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT054; 1:tuQ7X4WkPHWSeT3Gx80xrIftlf2fKRNHM6lP8F+TBMEWnjXSax5X2hUf9mCmCZsI713rcAGxoITrMN9w3mJvKGUdwO//VNela/9NR9KA37mAaSRHun17gRgIasujhtky X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f0800057-a41e-4f7b-b66f-08d4fc75017d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0501MB2078; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 3:CklDBsIyI1EZI8Jpr9M6gzDSMopOuP+scNpfXthof7AOqcKcFoW+rIRsj+LcDoA588xdG27IvtNlqXedZXuAQjs0/hM7psKlTlrw7XLMGqVksBflY4lEBb2/nXLuv8O6r2Z0NTcNDjd6IX9Y1X5Z658i+EWMY32JkTFA9cl7wkenxjhOao02RHx5SMT4sy9a+dDrC3pFKf5+hvZ0mAyg63A47F+RDFAtFeCz1dmyaD0ZzAbqqmhTykuphW7fY+a80Y6zkzo9IRIVb3024RiaM8czldsmL2B2mEbRFxiAlnTrXe2mea/gGIa/XBdvCic05UoXNmKfb5LnyFW1ah/SmrBBmZzCL/2fqRzavtn3e60=; 25:D2Ea2Uo+NRQWTEwOWTJ3v/gSF9WVsh4nEwdHV7cgX1QnAI6yZZ/lGKVyPszLRWFM2FOblPLw8n4Kq140ufxnm68YyFV4cqHj4lrGde+Hgah8ThuPcgwoBVXhSXCuxHR2CahfLoM1Bhpv2GA+xwbQgCrmHooT5XO+Fe+9WV5ZvmDCS1e9VjZYT87JpweSONZv4zNB+o/lSDmGcpgb0dw+Gxq+VNfPCc1fhf8CHNumTVSKeWEWUjweNMC2f1VETnrUsaP0aPt7le+RN/+3lfC4LylgC/9u4L/EmwHddMZei8RRAmqjtBruLD2hPhNPAmpsW5NgpjoI8fJKB3UGbBfNew== X-MS-TrafficTypeDiagnostic: SN1PR0501MB2078: X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 31:Tvi8fXvhcMMGLANx0xtL7Ca6imzUF60LnpX464RpyyU6wK3ZPwz1pECq3KWVrVizGTXjRjqex6aV8fqYSLe/5/lmN9uG2fYZi7s+MIi3yanbGVRwPwO4PhGJyoCTwDmH2VaNoYOYOCqqBJS5lJSxpEGpkbiK9F6hRqlk2Y5wvbxjM6AExlJlq5AlqdYndUehY4/mDWJFBddNISug4zQZ46BN63Iy673WzD/fcIxzJEo=; 20:U+YbJESXWetdhOVRuoaNQ1HF2JEkmZtdFKCllxCx01AvglIvV5SVdKFgJTvBfBvVXdfJgBlOcq9VLS4pDoLB0GQUj3mQ/vJ+Avqs0kdAhunx7lpuNl895kuZ7HI35OxPGF5ecPh742Z09ytfESd2AEs2M/la3H1q6KAuxbBBNKjEjmw8W8AgHKopsUrz0QBrN0Cp3xh++j6Dhz97FBb8qra0K1ycJHCQue/imjFjwzmZWjUw6XdpgwG3ZXC6szxMhSrFhkzLdLB3aslv8UhJPqz9M6anTbAj9Nprtox0CJROwyFJGtKNQKyja1dSO7SrY+wkd02ErgOpuVK4EA8CQfeHDruCEv5qYabZoeneuvgMMve6MvrVqk+YKg62XPCGH1z1O29CUcD20pQEVNqm0yoP7hVIonjjdrY5UTTOBbRISyxASmwgTqoOwPrberH+yBZ/KeG6SS0p30qMewa132skT39xrXjzz3Ib+wEaEDiqGTsLB9WOMKXQhiGK6WVF X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2078; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2078; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 4:QaB1Cqud6YFmF1uskLc3rr5C8zi/O/zi+hSD4mliXfmB0aLCLheKsTpprR53lIoDcB8bhlsmfZb+0IvBS8Ea46z/59gRlC0yNrwPTwyb525d0RR70qM2Kmc/m5EK+sMs2YYJ6h9FU8yacvnGFyDPYoOBcEbkDL5GyhF6f5Vc3xnvNEiYpeqcaxkLLvGwYdsEQmqeSgzOsLlvYyOhBMITid8JveNQrsxnvk9VpkZUEx/+QZfru99sLeOS8M2Ml+NR X-Forefront-PRVS: 0431F981D8 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2078; 23:s8gmomT5U09Nk1FmM6bu4EgteafOwNefavgC6fq?= =?us-ascii?Q?hMOo+g/v5ZwEdG8KelkzpkrwZ0zo0jLAJ1H1XGqUSlMtZxDGVMip/z7XmzZ+?= =?us-ascii?Q?sYlqoJaO/XSgA4S9IYy7cNfg367GN6pTbP3TNNdoTtxYKFr5DkU2yqTHR3iF?= =?us-ascii?Q?YOwRqCHZYLyUJctqrdIR6vcKviREv6x3B7V4Tyvc/ED7aKbNL4p9BjSeGeT9?= =?us-ascii?Q?MYzCKtV2+wRZC2PvPg60S9b7XecUiI6hWDZ2rJrAwzgTBwWOpf74eNzPFUYi?= =?us-ascii?Q?YyTrZF6W42xSBiXaPH6dP/7X6gEFJuwvCjPaTKDmZnVwqWlyQ8KjYfnLA77H?= =?us-ascii?Q?52IJG/rijW/aYT+hnYNk9FwBSauQtb3O0E8QKb5WlUQtrC1cAXyfMzsBQMIr?= =?us-ascii?Q?oVZSx4IOEAwDG9FSez5hsYpNvxMV2OkDbodHq0YZ0x4PhT+jJWWDVNAfaDj5?= =?us-ascii?Q?ogJumFXq/4inJ9gzXgUqk0ci4lEIwzDpVJiuvYpG1ViwY7CmrFvDJmX5lIdf?= =?us-ascii?Q?Ntq/sbFPo0DlagFhq9SnXmDf85ONuvN9X4LnELtYJxFuRX/jMGrGMcH43qWC?= =?us-ascii?Q?7jTBWvR99hjxBei22ae8PfYt0CcaoTqk89xOhKtc8SvQrJlcG7WNpgMMoSJz?= =?us-ascii?Q?ASxQa8k/pmrIP9scNDbi5tvItCSK904xZSk6lZ31D+6fHru+Luq4Bp5Crfsg?= =?us-ascii?Q?IvExWjrStEbgOy2Cl5juL2yKdxG9kbQa+4ud3kJ+04AQRV2zB/lEh9h3pkGZ?= =?us-ascii?Q?sH0HLhmef+DmyhhA+inx4U4fnokAjFZqE1z1zm0O54EKyMqdr58wRkfpgNqC?= =?us-ascii?Q?++NqofnQxKvXolj08bW+FgV0rnF4dhTV6P9FZSq0vLzyEftVyzmCq5CZJyW3?= =?us-ascii?Q?6Dk4tCRqanYWgBGTRKVN7Z44mq06DyqXbG8pkpXrA2IX0qJ7mqf/OQDf+ayt?= =?us-ascii?Q?dFPrXWXWd6wkfYBi4t9vqS9Gpm6pre9+YjRu9Vlp4ApDM5YLj//VR9XxatuY?= =?us-ascii?Q?xmCB0lUSpF+xQDa0FjhBUmTr63YfZpygq68aqjTH4+4OMM5H/q+AajMaBDvB?= =?us-ascii?Q?VXD7mSXEkF35jYLSREvQPrw4o2puDTgC8Yhz2u10KzfrQZ93kDJMr56gKfZV?= =?us-ascii?Q?edpxOBaykqT2u9Q/oZQnd51m7l9I195JDabf8Tv/AmNdNzdWvk/PUm2SsCSH?= =?us-ascii?Q?R7gNbuJBgy6Tm7qi1A3VEHNZGtGqnFcPiTDEjzfJFsXRQtrUSzVlCuoSoNgQ?= =?us-ascii?Q?rXsOXQ7ftM0pKGJO9HiXD74AS/gVDr1/ikQvCqRGnAI9VXPCRc4pgkB/1BFH?= =?us-ascii?Q?EQvCbfwRPvPX6WYT/oe+OxDA2omHu9/ln08Nd1ggSyHFJJNyyoue6R4SSyvP?= =?us-ascii?Q?RoGHeuTb4JTgqNTc/p+TBTl6KFr4=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 6:bVi+tkp2O2Q9oyHZAso8SC69PJVeH8GENCbi1rQTqSwZGPOikQ0f71sYT9jbXiM2tRtuU27DSFXVQ2foz4fSJRyu8xJ0nyqSF2lDuJTeUKRxMcg7UamAsWxH41Yi0ZRL7ga7S8jyWMd2MJfGCgWHsLwgvxeU060c9b6Cqy4WZP+sVH7xdQ93NKugxTY6CKT5SZm99OtkXJu62UADP58LYMH65+Z1jcx8Yz2URubdwKJYUttXcanT8OlK6QBHq7v1JvSeDs0Iu63k3bw/+MKPSsEaewKfkILzjBJ9XqveDk500Cq+xJPAI8PBojG6KYipY1WAIjnmp0iFCuawClhBtA==; 5:IeEn1zwQ3NClF1W5a1tuHR+IvGRP+C78JOikc2Y8zRASAZU+2cQBCyew1JDvD0fMuZPQLjHSliJRiKR6XUHEOwCS1w7MGCOhUV7QIkv31vvPnKhVEgOBbw7o2u7QcuGqBt9ua7NSj80Kcpa1Uxmbxw==; 24:5p6rD084kIJ3TiRNRwuwdeyPxBx1AiqAFVBbSxnNzhyK0QdD5AviCeIMfk8XKAGQdbEvDxwOEbhL7YgM/PAsI4olT8MrGpaT3GQ3cBahPQ8=; 7:0KYJU2gjw/pReEj4q54F2iOG5/4UWnoFBOJCSDW2vvmxCpa1z3TZle3q8npRdwlPAA1PXExK5h6ZiLvbVT1c/nmh/Bjq3bA3BckvAJX/TJLEDuJXdpZv+kh3aNwUsG7gbCdGpbuoT3E61Fi0LYwFqmkYBZA4rmrfyKzk8Omw5EnnkXxh9d9m+pgPI3bAwNpU4yhbv3wvM3qaEewbl27I70ydwyPMafUdCoz9TrDr6Hk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 20:04:43.0127 (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: SN1PR0501MB2078 Archived-At: Subject: Re: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 20:04:47 -0000 Hi, I have uploaded -09 of this draft. https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-09 It has two changes: 1) RFC6234 is now a normative reference. 2) ipr="trust200902" I believe this has addressed all of the public and private review comments I have received to date. -- Mark From nobody Fri Sep 15 13:42: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 1AE12132944; Fri, 15 Sep 2017 13:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=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 rEfgt8CsDnpV; Fri, 15 Sep 2017 13:42:19 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCD8126E64; Fri, 15 Sep 2017 13:42:19 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id i195so2141417pgd.9; Fri, 15 Sep 2017 13:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=98YHEnWOi7GU7T0vDelO+OjFtqQKVHYrUiTgjP05XYc=; b=DVBVKNu2/CW0Z29ZMQXib/5aNSyVjuopoiN64zreW8D9HWuXaWYXcbG/IthO0wmpSh I9FY83QgmticiAONz7swwQITOLmWQET8SAHI6k9T8SlhEHauDgb4ZLNtVj1L5iJ+bhqq ahWaMpk2GDaQnW8WTWntgYwV40eW0/bZGExpsQMuYbkdFccVkMWxyr+c9XXdBf0XN0ku o8HwZBIo70AIijFEUJPHIC0VcjZCVzZND0XMr2J6F9wjjSA4hBG0Lv3tSpAkniwPqdT2 r5b87eMWEUD8CYn8XpLaMMLfUzbcF9OApYTbXp5580n4bV1/GARdzIfMJPM6kLToqqCz mPgA== 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:cc; bh=98YHEnWOi7GU7T0vDelO+OjFtqQKVHYrUiTgjP05XYc=; b=hGr6YT8FlQ9rmCF3R6FKIlF7u7RD1BXfqtS4VKjXDJW5eMApx4ybJjL16TCWQcP5ea SO6Hy5FaCpSOQa90Y2eEp5vDJ0p4eoMAPBn4ecw313LcP3b5k/+FaM14pNSFLt+JxDH8 kiNc77A02JrN3wYtXwOAgrj12UCZeLQ2QP5MVWs5CB3M6DjXbfLVh6VmhUQDn2OSQb7v yTvQXv3BR/joaz970MwUS0V2PDEAcwP7fAzTSPmBWThEZKZMagO1v3arEyPvjyTU8Oc+ +CHNKZGjdALkwFCa7BDHEgXin0QVGlpgJTX4tVZ6qAfksVDnJsd722X629cz6RV7/YCn xK5A== X-Gm-Message-State: AHPjjUhhVv6lj8XgeRfIL6q8TEarH1i4xy6HsC8ntVTEp6ayuDJmcvUO 5TRpk7HUXwkdD76OjDJwdaeBFBUyBvFAXPycMc0= X-Google-Smtp-Source: AOwi7QD00gLLR4YNHOW6GL6kDS2s1VUiIj8BzMKGFBRROD+jE7rnqdZqrhWmsgA5+V30rEb5t+XrfqD5PflX7kgEfZ8= X-Received: by 10.98.103.89 with SMTP id b86mr854303pfc.319.1505508138869; Fri, 15 Sep 2017 13:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Fri, 15 Sep 2017 13:41:38 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 15 Sep 2017 16:41:38 -0400 Message-ID: To: "Mark D. Baushke" Cc: "Salz, Rich" , Spencer Dawkins at IETF , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 20:42:21 -0000 Hi Mark, On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke wrote: > Kathleen Moriarty writes: > >> Mark, >> >> Thanks for your detailed response, I appreciate it. Inline. > > Trimmed response, likewise inline. > >> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke wrote: >> > Salz, Rich writes: >> > >> Embedded equipment is a tough problem. > > Yes. > >> So for this, your worried about new purchases. > >> If it's already purchased, then we are talking an audit issue and >> possibly not having funds to buy some million dollar piece of >> equipment that happens to support less than 2048. > > Well, one hopes that with a million dollar piece of equipment, there is > a support cotract and a way to update the software in that box. One would think, but that's a real example and nothing could be done. It's not uncommon either. > > I was more concerned with needing to sell software to manage thousands > of very low price embedded devices and still be able to inter-operate > between the management station and the devices. > > For example, a conformant implementation that MUST use 2048 bit keys, > but needs to talk to a device only able to use 1024 bit keys has a > problem. Likewise if the embedded devices only support > diffie-hellman-group1-sha1 as they were two small and slow to manage > with diffie-hellman-group14-sha1 when deployed as a read-only device. > > Does my management station get to talk to those old devices when MUST is > present and exact conformance to the specification is mandated? OK, thanks for providing that example, it's helpful and I see your point better now. > >> Hmm, in the past, I've done thing to mitigate threats like isolating >> such hosts when the threat warranted measures. I see your point, I'm >> just trying to walk through real instances of issues to make sure we >> are considering options well. > > Yes, and I really appreciate that we are getting this into the archive. > >> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the >> > word "MUST" for the current 1024 bit value. So, in this case, just >> > updating a SHOULD from a SHOULD seems reasonable to me. If it were a >> > MUST, then I would probably advocate for SHOULD NOT as the step down. >> > >> > For example, I would have no objection to adding text which says that >> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than >> > 2048. >> > >> > fwiw: I also suspect that 2048 will not survive more than another couple >> > of years and would not mind saying that "n SHOULD be 3072 or greater". I >> > do not believe that view is accepted by everyone, so 2048 bits is what >> > is in place for now. >> >> Hmm, than it would be good to make a note of this so those who are >> replacing embedded equipment make the leap to a higher value than >> 2048. This can be in the non normative text. > > So, using words like 'desirable' rather than recommended or should? > I guess that might be a way to approach it for this particular draft. > > I am less certain how to deal with the more general issue of algorithm > deprecation in the security area. Guessing wrong can be very expensive. > >> There are a few published RFCs (I think some CMS RFCs) that took on a >> notion of SHOULD - and SHOULD + as well as MUST + MUST -. I see the >> JOSE algorithms RFC also uses recommended + and recommended -. The >> minus shows that although this is kinda okay now, it really isn't >> recommended and shouldn't be in new products. > > Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2 > and eventually removed it due to comments not liking it. Hmm, I still see a table with the SHOULD, MUST, etc. listed out for that draft? I don't see the use of SHOULD +/-, MUST +/- and think it might help in cases like this draft where you have mushy guidance. I still think some warning that 2048 as the minimum recommendation may change to 3072 or greater in a couple of years should be in a non normative statement for developers to plan ahead as a minimum. > >> Do you think that approach could help to allow some flexibility, but >> also show 1024 is on it's way out the door and 2048 will follow soon? > > I do not think that moving to 'a min value of 2048 SHOULD+ be used' > will do much to help this particular case. I would actually be recommending min value of SHOULD - as it will not be recommended in a few years and is on a decline. SHOULD + typically indicates that it will be required as a MUST next, whereas in this case, it will be deprecated in a few years. Thanks, Kathleen > > -- Mark -- Best regards, Kathleen From nobody Fri Sep 15 15:05: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 5BAF5134226; Fri, 15 Sep 2017 15:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, LOTS_OF_MONEY=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 dLv0epLS06D0; Fri, 15 Sep 2017 15:05:26 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9F0133209; Fri, 15 Sep 2017 15:05:25 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l4so2228318ywa.6; Fri, 15 Sep 2017 15:05:25 -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=hxsjyVTSlLIOuAgIp4VHJcihh6OAxnplFtxSA6fr2Xc=; b=j3bpjVCGeHdQAzjWrBKJASxf67P2yPTJ/nUmfWCYcqDwLZ4Cz1XWMz6xApXJMdju2o n3uMYhKqx/Hxf+w51nGPcW63BlUgR+8NuU/5LAzQNnVyM45H4P93lZQWtYo7o8OL+jlw IcLBBuBzZmnTCHrnoCgmxKniKv5Ii6xPwMT5ESMfa0KoFbm9kLMfKrj+b6fPc/crRTcT RAotEq39CvhS4+f4rS6rKr6uQBTm9+NbfAp+tZW+z5EwXaAR/K9ZPg6qPqnYB9DiCy4o ljA5YqsWSrT2On5aoKzBFJ3VVEJ8wo2ypXvOGyjVG1WFEA2HRDnkhgHQkg/QmoXqtHrL G3Ig== 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=hxsjyVTSlLIOuAgIp4VHJcihh6OAxnplFtxSA6fr2Xc=; b=pQr1rhmwi2v1mSzUC4FJv8uVfZK2lNtiYhWrMHX4FAdAuQH5xnmO9VBD0vpUgWl9Jh A7F8IVyM4nI8S+Gulhm5FQXrc2Nj8UqhhvnwlDanSa6BoDwQu0/kl7c7jrRRfH7EVizZ Yz8l1sxUzecfcInFCpWZxHOh2mtVWQLLph/RhbYkZcd8dcyhx8plVHznDHlpWp700DWq 7bZom0jSKy3k3vUG8lUoYhAtjsEW/NJAj6AFZ3+ApVWRCHI9LKfNM2F24Ie77iXYRQf9 fXh5ldp5lDV8aJ06WbNdOcO3SZ5WXRECDrw4isAjLJWbEPghCk4quMdmSddik1tPdrv5 rhzQ== X-Gm-Message-State: AHPjjUiAUO8hUMD3jJ/czhpMMze8LRTz41Ll3Q7ttT7zJFXjFOTOv9D6 MHP00tiyGUMsWx2t5RuUVJg3xjYyD+MLyfvEpVE= X-Google-Smtp-Source: AOwi7QDyHpb7LRK2e6YXXaIlMAy5k6HV2BQJ8b5sPwYPgux6xMuVmo1CnogTN690tDzWP0d7MFbfkENqrZphmFHqalE= X-Received: by 10.37.216.14 with SMTP id p14mr19605817ybg.75.1505513124967; Fri, 15 Sep 2017 15:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Fri, 15 Sep 2017 15:05:24 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Fri, 15 Sep 2017 17:05:24 -0500 Message-ID: To: Kathleen Moriarty Cc: "Mark D. Baushke" , "Salz, Rich" , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Type: multipart/alternative; boundary="001a114fd3b204ba2e0559419712" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Sep 2017 22:05:28 -0000 --001a114fd3b204ba2e0559419712 Content-Type: text/plain; charset="UTF-8" Speaking as someone whose primary connection to crypto is transporting bytes whether the transport protocol can understand them or not ... On Fri, Sep 15, 2017 at 3:41 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Mark, > > On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke wrote: > > Kathleen Moriarty writes: > > > >> Mark, > >> > >> Thanks for your detailed response, I appreciate it. Inline. > > > > Trimmed response, likewise inline. > > > >> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke > wrote: > >> > Salz, Rich writes: > >> > > >> Embedded equipment is a tough problem. > > > > Yes. > > > >> So for this, your worried about new purchases. > > > >> If it's already purchased, then we are talking an audit issue and > >> possibly not having funds to buy some million dollar piece of > >> equipment that happens to support less than 2048. > > > > Well, one hopes that with a million dollar piece of equipment, there is > > a support cotract and a way to update the software in that box. > > One would think, but that's a real example and nothing could be done. > It's not uncommon either. > > > > > I was more concerned with needing to sell software to manage thousands > > of very low price embedded devices and still be able to inter-operate > > between the management station and the devices. > > > > For example, a conformant implementation that MUST use 2048 bit keys, > > but needs to talk to a device only able to use 1024 bit keys has a > > problem. Likewise if the embedded devices only support > > diffie-hellman-group1-sha1 as they were two small and slow to manage > > with diffie-hellman-group14-sha1 when deployed as a read-only device. > > > > Does my management station get to talk to those old devices when MUST is > > present and exact conformance to the specification is mandated? > > OK, thanks for providing that example, it's helpful and I see your > point better now. > > > > >> Hmm, in the past, I've done thing to mitigate threats like isolating > >> such hosts when the threat warranted measures. I see your point, I'm > >> just trying to walk through real instances of issues to make sure we > >> are considering options well. > > > > Yes, and I really appreciate that we are getting this into the archive. > > > >> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the > >> > word "MUST" for the current 1024 bit value. So, in this case, just > >> > updating a SHOULD from a SHOULD seems reasonable to me. If it were a > >> > MUST, then I would probably advocate for SHOULD NOT as the step down. > >> > > >> > For example, I would have no objection to adding text which says that > >> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less > than > >> > 2048. > >> > > >> > fwiw: I also suspect that 2048 will not survive more than another > couple > >> > of years and would not mind saying that "n SHOULD be 3072 or > greater". I > >> > do not believe that view is accepted by everyone, so 2048 bits is what > >> > is in place for now. > >> > >> Hmm, than it would be good to make a note of this so those who are > >> replacing embedded equipment make the leap to a higher value than > >> 2048. This can be in the non normative text. > I've had a comment with someone within the last 24 hours about whether having text that says, roughly, if you're using less than 2048 bits and can't go higher, you should probably expect that if this does become a MUST, that might happen very suddenly ("attack + CERT advisory + vendors who can go higher turning off anything lower than 2048 = you can only talk to people who can't do 2048, and they're all vulnerable to a known exploit" is a layperson's understanding, but I hope that's not too muddy to make sense). If that was a decent idea, and "you might want to be adding 3072 if you can't do it now" is a good idea, this is turning into an advisory section, and I like that, even if you don't have consensus for normative statements now. Is that going to make things better? (I'm assuming it won't make them perfect) Spencer > > > > So, using words like 'desirable' rather than recommended or should? > > I guess that might be a way to approach it for this particular draft. > > > > I am less certain how to deal with the more general issue of algorithm > > deprecation in the security area. Guessing wrong can be very expensive. > > > >> There are a few published RFCs (I think some CMS RFCs) that took on a > >> notion of SHOULD - and SHOULD + as well as MUST + MUST -. I see the > >> JOSE algorithms RFC also uses recommended + and recommended -. The > >> minus shows that although this is kinda okay now, it really isn't > >> recommended and shouldn't be in new products. > > > > Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2 > > and eventually removed it due to comments not liking it. > > Hmm, I still see a table with the SHOULD, MUST, etc. listed out for > that draft? I don't see the use of SHOULD +/-, MUST +/- and think it > might help in cases like this draft where you have mushy guidance. > > I still think some warning that 2048 as the minimum recommendation may > change to 3072 or greater in a couple of years should be in a non > normative statement for developers to plan ahead as a minimum. > > > > >> Do you think that approach could help to allow some flexibility, but > >> also show 1024 is on it's way out the door and 2048 will follow soon? > > > > I do not think that moving to 'a min value of 2048 SHOULD+ be used' > > will do much to help this particular case. > > I would actually be recommending min value of SHOULD - as it will not > be recommended in a few years and is on a decline. SHOULD + typically > indicates that it will be required as a MUST next, whereas in this > case, it will be deprecated in a few years. > > Thanks, > Kathleen > > > > > -- Mark > > > > -- > > Best regards, > Kathleen > --001a114fd3b204ba2e0559419712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as someone whose primary connection to crypto is = transporting bytes whether the transport protocol can understand them or no= t ...

On Fri, Sep = 15, 2017 at 3:41 PM, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> wrote:
Hi Ma= rk,

On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke <mdb@juniper.net> wrote:
> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> writes:
>
>> Mark,
>>
>> Thanks for your detailed response, I appreciate it.=C2=A0 Inline.<= br> >
> Trimmed response, likewise inline.
>
>> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke <mdb@juniper.net> wrote:
>> > Salz, Rich <rsalz@akam= ai.com> writes:
>> >
>> Embedded equipment is a tough problem.
>
> Yes.
>
>> So for this, your worried about new purchases.
>
>> If it's already purchased, then we are talking an audit issue = and
>> possibly not having funds to buy some million dollar piece of
>> equipment that happens to support less than 2048.
>
> Well, one hopes that with a million dollar piece of equipment, there i= s
> a support cotract and a way to update the software in that box.

One would think, but that's a real example and nothing could be = done.
It's not uncommon either.

>
> I was more concerned with needing to sell software to manage thousands=
> of very low price embedded devices and still be able to inter-operate<= br> > between the management station and the devices.
>
> For example, a conformant implementation that MUST use 2048 bit keys,<= br> > but needs to talk to a device only able to use 1024 bit keys has a
> problem. Likewise if the embedded devices only support
> diffie-hellman-group1-sha1 as they were two small and slow to manage > with diffie-hellman-group14-sha1 when deployed as a read-only device.<= br> >
> Does my management station get to talk to those old devices when MUST = is
> present and exact conformance to the specification is mandated?

OK, thanks for providing that example, it's helpful and I see yo= ur
point better now.

>
>> Hmm, in the past, I've done thing to mitigate threats like iso= lating
>> such hosts when the threat warranted measures. I see your point, I= 'm
>> just trying to walk through real instances of issues to make sure = we
>> are considering options well.
>
> Yes, and I really appreciate that we are getting this into the archive= .
>
>> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 doe= s not use the
>> > word "MUST" for the current 1024 bit value. So, in = this case, just
>> > updating a SHOULD from a SHOULD seems reasonable to me. If it= were a
>> > MUST, then I would probably advocate for SHOULD NOT as the st= ep down.
>> >
>> > For example, I would have no objection to adding text which s= ays that
>> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be= less than
>> > 2048.
>> >
>> > fwiw: I also suspect that 2048 will not survive more than ano= ther couple
>> > of years and would not mind saying that "n SHOULD be 307= 2 or greater". I
>> > do not believe that view is accepted by everyone, so 2048 bit= s is what
>> > is in place for now.
>>
>> Hmm, than it would be good to make a note of this so those who are=
>> replacing embedded equipment make the leap to a higher value than<= br> >> 2048.=C2=A0 This can be in the non normative text.
=

I've had a comment with someone within= the last 24 hours about whether having text that says, roughly, if you'= ;re using less than 2048 bits and can't go higher, you should probably = expect that if this does become a MUST, that might happen very suddenly (&q= uot;attack + CERT advisory + vendors who can go higher turning off anything= lower than 2048 =3D you can only talk to people who can't do 2048, and= they're all vulnerable to a known exploit" is a layperson's u= nderstanding, but I hope that's not too muddy to make sense).

If that was a decent idea, and "you might want to be a= dding 3072 if you can't do it now" is a good idea, this is turning= into an advisory section, and I like that, even if you don't have cons= ensus for normative statements now.

Is that going = to make things better? (I'm assuming it won't make them perfect)

Spencer
=C2=A0
>
> So, using words like 'desirable' rather than recommended or sh= ould?
> I guess that might be a way to approach it for this particular draft.<= br> >
> I am less certain how to deal with the more general issue of algorithm=
> deprecation in the security area. Guessing wrong can be very expensive= .
>
>> There are a few published RFCs (I think some CMS RFCs) that took o= n a
>> notion of SHOULD - and SHOULD + as well as MUST + MUST -.=C2=A0 I = see the
>> JOSE algorithms RFC also uses recommended + and recommended -.=C2= =A0 The
>> minus shows that although this is kinda okay now, it really isn= 9;t
>> recommended and shouldn't be in new products.
>
> Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2=
> and eventually removed it due to comments not liking it.

Hmm, I still see a table with the SHOULD, MUST, etc. listed out= for
that draft?=C2=A0 I don't see the use of SHOULD +/-, MUST +/- and think= it
might help in cases like this draft where you have mushy guidance.

I still think some warning that 2048 as the minimum recommendation may
change to 3072 or greater in a couple of years should be in a non
normative statement for developers to plan ahead as a minimum.

>
>> Do you think that approach could help to allow some flexibility, b= ut
>> also show 1024 is on it's way out the door and 2048 will follo= w soon?
>
> I do not think that moving to 'a min value of 2048=C2=A0 SHOULD+ b= e used'
> will do much to help this particular case.

I would actually be recommending min value of SHOULD - as it will no= t
be recommended in a few years and is on a decline.=C2=A0 SHOULD + typically=
indicates that it will be required as a MUST next, whereas in this
case, it will be deprecated in a few years.

Thanks,
Kathleen

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



--

Best regards,
Kathleen

--001a114fd3b204ba2e0559419712-- From nobody Fri Sep 15 18:03: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 999131323B4; Fri, 15 Sep 2017 18:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, LOTS_OF_MONEY=0.001, MIME_QP_LONG_LINE=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 ILdxvmG355tS; Fri, 15 Sep 2017 18:03:15 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 A76B4126B71; Fri, 15 Sep 2017 18:03:15 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i13so3593146qtc.11; Fri, 15 Sep 2017 18:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jzD3TjFA5+wvIfdt6P/6oXQDJOdNJsUztl4ANLZEpeQ=; b=Sl6syIaTFcFFJ8+36Gag3t8gp8KUXk14xXiHbaiSmU3XG5UREoF/YK3fzoMPopQKIw owmDZvPpz8ZG9Cnp8qPJJPL8AdupK/7Y+OF3gx+zH7uG6l2VuBZ4e1MDfEK7W/zwdUK5 yH//Z/vNXOLzIF7FRyjqbklyID7Ri382jjZnf0oooA7uqkq2Y4sRkH21+xx/IwrltGxL MlNQkM+orhehS8alTAvFhuzYUMiu7wVqAd97mE3efrIg7tvTwgAg8LbGDU/63I2gqRKU auk8Oaznnh95TtYM0jLTQ2jRYpbY0WPqHURT2pBuF6m3nm4Iz6rVxIlAo0wsY3NGxUQF z70Q== 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=jzD3TjFA5+wvIfdt6P/6oXQDJOdNJsUztl4ANLZEpeQ=; b=ZYlmObjwpXif5O8tYqI1FJTc+1rFptmDD/WymaEjIqlsZowLGfp6ojx8XmaFEbsajC DQeTH+XhEv2y3rZ73/Rx/Pw9d4LWf8Q6K713H1D2tZKoRNpdXUWiu0PrNRxrQmd1d5gH rAlBN9LyMmoYoZbF9uSN/2kfEPRiyxAtMGNMzZwi9m6GugHvhVkVWe1wQ/kfmBbJYPrw R2rtLn8af1m45EI0TrC4hf/2EyGVXkOT67kMC66X4pNxZ6AjkrDcjsFvBT2ZjKqF3s6c +54FV89IDhu4ZoZY+zAtHQM2EzBXhCC7JRs85r6WDw/8kzQsu9NHIGL0LczyCuEs9S5/ Alyg== X-Gm-Message-State: AHPjjUhoGsuOKavPkayVblJ9JLy+DUvLtk3JVTKOFvVlyu+W37kr0ALB zDTarAdvFcQHs8UYGkY= X-Google-Smtp-Source: AOwi7QCWf+SEj/qAkPGK2gHXn5b4AMJ1VgwPH1KvLtLWK/5iejR2AtROazEEtk03yXv/a/oFVnvh6g== X-Received: by 10.237.42.79 with SMTP id k15mr38424421qtf.222.1505523794587; Fri, 15 Sep 2017 18:03:14 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id i84sm1483626qkh.17.2017.09.15.18.03.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 18:03:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-296DF410-C223-4BA5-9F78-27D1B9CD2D59 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 15 Sep 2017 21:03:12 -0400 Cc: "Mark D. Baushke" , "Salz, Rich" , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault Content-Transfer-Encoding: 7bit Message-Id: References: To: Spencer Dawkins at IETF Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Sep 2017 01:03:19 -0000 --Apple-Mail-296DF410-C223-4BA5-9F78-27D1B9CD2D59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Sent from my iPhone > On Sep 15, 2017, at 6:05 PM, Spencer Dawkins at IETF wrote: >=20 > Speaking as someone whose primary connection to crypto is transporting byt= es whether the transport protocol can understand them or not ... >=20 >> On Fri, Sep 15, 2017 at 3:41 PM, Kathleen Moriarty wrote: >> Hi Mark, >>=20 >> On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke wrote:= >> > Kathleen Moriarty writes: >> > >> >> Mark, >> >> >> >> Thanks for your detailed response, I appreciate it. Inline. >> > >> > Trimmed response, likewise inline. >> > >> >> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke wro= te: >> >> > Salz, Rich writes: >> >> > >> >> Embedded equipment is a tough problem. >> > >> > Yes. >> > >> >> So for this, your worried about new purchases. >> > >> >> If it's already purchased, then we are talking an audit issue and >> >> possibly not having funds to buy some million dollar piece of >> >> equipment that happens to support less than 2048. >> > >> > Well, one hopes that with a million dollar piece of equipment, there is= >> > a support cotract and a way to update the software in that box. >>=20 >> One would think, but that's a real example and nothing could be done. >> It's not uncommon either. >>=20 >> > >> > I was more concerned with needing to sell software to manage thousands >> > of very low price embedded devices and still be able to inter-operate >> > between the management station and the devices. >> > >> > For example, a conformant implementation that MUST use 2048 bit keys, >> > but needs to talk to a device only able to use 1024 bit keys has a >> > problem. Likewise if the embedded devices only support >> > diffie-hellman-group1-sha1 as they were two small and slow to manage >> > with diffie-hellman-group14-sha1 when deployed as a read-only device. >> > >> > Does my management station get to talk to those old devices when MUST i= s >> > present and exact conformance to the specification is mandated? >>=20 >> OK, thanks for providing that example, it's helpful and I see your >> point better now. >>=20 >> > >> >> Hmm, in the past, I've done thing to mitigate threats like isolating >> >> such hosts when the threat warranted measures. I see your point, I'm >> >> just trying to walk through real instances of issues to make sure we >> >> are considering options well. >> > >> > Yes, and I really appreciate that we are getting this into the archive.= >> > >> >> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use th= e >> >> > word "MUST" for the current 1024 bit value. So, in this case, just >> >> > updating a SHOULD from a SHOULD seems reasonable to me. If it were a= >> >> > MUST, then I would probably advocate for SHOULD NOT as the step down= . >> >> > >> >> > For example, I would have no objection to adding text which says tha= t >> >> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less t= han >> >> > 2048. >> >> > >> >> > fwiw: I also suspect that 2048 will not survive more than another co= uple >> >> > of years and would not mind saying that "n SHOULD be 3072 or greater= ". I >> >> > do not believe that view is accepted by everyone, so 2048 bits is wh= at >> >> > is in place for now. >> >> >> >> Hmm, than it would be good to make a note of this so those who are >> >> replacing embedded equipment make the leap to a higher value than >> >> 2048. This can be in the non normative text. >=20 > I've had a comment with someone within the last 24 hours about whether hav= ing text that says, roughly, if you're using less than 2048 bits and can't g= o higher, you should probably expect that if this does become a MUST, that m= ight happen very suddenly ("attack + CERT advisory + vendors who can go high= er turning off anything lower than 2048 =3D you can only talk to people who c= an't do 2048, and they're all vulnerable to a known exploit" is a layperson'= s understanding, but I hope that's not too muddy to make sense). I wish, but until it's phased out, some hosts will have no choice but to tal= k to hosts at 1024. That's why I'm poking at this a bit, how much can we im= prove things deployed/being deployed. >=20 > If that was a decent idea, and "you might want to be adding 3072 if you ca= n't do it now" is a good idea, this is turning into an advisory section, and= I like that, even if you don't have consensus for normative statements now.= >=20 > Is that going to make things better? (I'm assuming it won't make them perf= ect) How about something along the lines of (please tweak, this is off the cuff):= It's recommended that you implement no less than 3072 bits in new deployment= s with the expectation of a minimum of 3072 bits within a few years. It's u= nderstood that devices will be deployed for many years and implementing to t= he bare minimum recommended value is not advised. Thank you & at the end of the day, I balloted yes but hope that we provide g= ood guidance for implementors. Best regards, Kathleen=20 >=20 > Spencer > =20 >> > >> > So, using words like 'desirable' rather than recommended or should? >> > I guess that might be a way to approach it for this particular draft. >> > >> > I am less certain how to deal with the more general issue of algorithm >> > deprecation in the security area. Guessing wrong can be very expensive.= >> > >> >> There are a few published RFCs (I think some CMS RFCs) that took on a >> >> notion of SHOULD - and SHOULD + as well as MUST + MUST -. I see the >> >> JOSE algorithms RFC also uses recommended + and recommended -. The >> >> minus shows that although this is kinda okay now, it really isn't >> >> recommended and shouldn't be in new products. >> > >> > Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2 >> > and eventually removed it due to comments not liking it. >>=20 >> Hmm, I still see a table with the SHOULD, MUST, etc. listed out for >> that draft? I don't see the use of SHOULD +/-, MUST +/- and think it >> might help in cases like this draft where you have mushy guidance. >>=20 >> I still think some warning that 2048 as the minimum recommendation may >> change to 3072 or greater in a couple of years should be in a non >> normative statement for developers to plan ahead as a minimum. >>=20 >> > >> >> Do you think that approach could help to allow some flexibility, but >> >> also show 1024 is on it's way out the door and 2048 will follow soon? >> > >> > I do not think that moving to 'a min value of 2048 SHOULD+ be used' >> > will do much to help this particular case. >>=20 >> I would actually be recommending min value of SHOULD - as it will not >> be recommended in a few years and is on a decline. SHOULD + typically >> indicates that it will be required as a MUST next, whereas in this >> case, it will be deprecated in a few years. >>=20 >> Thanks, >> Kathleen >>=20 >> > >> > -- Mark >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 --Apple-Mail-296DF410-C223-4BA5-9F78-27D1B9CD2D59 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sent from my iPhone

On Sep 15, 2017, at 6:05 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> w= rote:

Speaking a= s someone whose primary connection to crypto is transporting bytes whether t= he transport protocol can understand them or not ...

On Fri, Sep 15, 2017 at 3:41 PM, Kathleen M= oriarty <kathleen.moriarty.ietf@gmail.com> wrot= e:
Hi Mark,

On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke <mdb@juniper.net> wrote:
> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> writes:
>
>> Mark,
>>
>> Thanks for your detailed response, I appreciate it.  Inline. >
> Trimmed response, likewise inline.
>
>> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke <mdb@juniper.net> wrote:
>> > Salz, Rich <rsalz@akama= i.com> writes:
>> >
>> Embedded equipment is a tough problem.
>
> Yes.
>
>> So for this, your worried about new purchases.
>
>> If it's already purchased, then we are talking an audit issue and >> possibly not having funds to buy some million dollar piece of
>> equipment that happens to support less than 2048.
>
> Well, one hopes that with a million dollar piece of equipment, there is=
> a support cotract and a way to update the software in that box.

One would think, but that's a real example and nothing could be done.=
It's not uncommon either.

>
> I was more concerned with needing to sell software to manage thousands<= br> > of very low price embedded devices and still be able to inter-operate > between the management station and the devices.
>
> For example, a conformant implementation that MUST use 2048 bit keys, > but needs to talk to a device only able to use 1024 bit keys has a
> problem. Likewise if the embedded devices only support
> diffie-hellman-group1-sha1 as they were two small and slow to manage > with diffie-hellman-group14-sha1 when deployed as a read-only device. >
> Does my management station get to talk to those old devices when MUST i= s
> present and exact conformance to the specification is mandated?

OK, thanks for providing that example, it's helpful and I see your point better now.

>
>> Hmm, in the past, I've done thing to mitigate threats like isolatin= g
>> such hosts when the threat warranted measures. I see your point, I'= m
>> just trying to walk through real instances of issues to make sure w= e
>> are considering options well.
>
> Yes, and I really appreciate that we are getting this into the archive.=
>
>> > For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does= not use the
>> > word "MUST" for the current 1024 bit value. So, in this case, j= ust
>> > updating a SHOULD from a SHOULD seems reasonable to me. If it w= ere a
>> > MUST, then I would probably advocate for SHOULD NOT as the ste= p down.
>> >
>> > For example, I would have no objection to adding text which sa= ys that
>> > the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be l= ess than
>> > 2048.
>> >
>> > fwiw: I also suspect that 2048 will not survive more than anot= her couple
>> > of years and would not mind saying that "n SHOULD be 3072 or g= reater". I
>> > do not believe that view is accepted by everyone, so 2048 bits= is what
>> > is in place for now.
>>
>> Hmm, than it would be good to make a note of this so those who are<= br> >> replacing embedded equipment make the leap to a higher value than >> 2048.  This can be in the non normative text.
<= /blockquote>

I've had a comment with someone within the l= ast 24 hours about whether having text that says, roughly, if you're using l= ess than 2048 bits and can't go higher, you should probably expect that if t= his does become a MUST, that might happen very suddenly ("attack + CERT advi= sory + vendors who can go higher turning off anything lower than 2048 =3D yo= u can only talk to people who can't do 2048, and they're all vulnerable to a= known exploit" is a layperson's understanding, but I hope that's not too mu= ddy to make sense).

I wish, but until it's phased out, some hosts will have no choice but to ta= lk to hosts at 1024.  That's why I'm poking at this a bit, how much can= we improve things deployed/being deployed.


If that was a decent idea, and "you might want to be a= dding 3072 if you can't do it now" is a good idea, this is turning into an a= dvisory section, and I like that, even if you don't have consensus for norma= tive statements now.

Is that going to make things b= etter? (I'm assuming it won't make them perfect)

How about something along the lines of (p= lease tweak, this is off the cuff):

It's recommended tha= t you implement no less than 3072 bits in new deployments with the expectati= on of a minimum of 3072 bits within a few years.  It's understood that d= evices will be deployed for many years and implementing to the bare minimum r= ecommended value is not advised.

Thank you & at= the end of the day, I balloted yes but hope that we provide good guidance f= or implementors.

Best regards,
Kathleen&n= bsp;

Spencer
&nbs= p;
>
> So, using words like 'desirable' rather than recommended or should?
= > I guess that might be a way to approach it for this particular draft. >
> I am less certain how to deal with the more general issue of algorithm<= br> > deprecation in the security area. Guessing wrong can be very expensive.=
>
>> There are a few published RFCs (I think some CMS RFCs) that took on= a
>> notion of SHOULD - and SHOULD + as well as MUST + MUST -.  I s= ee the
>> JOSE algorithms RFC also uses recommended + and recommended -. = ; The
>> minus shows that although this is kinda okay now, it really isn't >> recommended and shouldn't be in new products.
>
> Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2<= br> > and eventually removed it due to comments not liking it.

Hmm, I still see a table with the SHOULD, MUST, etc. listed out f= or
that draft?  I don't see the use of SHOULD +/-, MUST +/- and think it might help in cases like this draft where you have mushy guidance.

I still think some warning that 2048 as the minimum recommendation may
change to 3072 or greater in a couple of years should be in a non
normative statement for developers to plan ahead as a minimum.

>
>> Do you think that approach could help to allow some flexibility, bu= t
>> also show 1024 is on it's way out the door and 2048 will follow soo= n?
>
> I do not think that moving to 'a min value of 2048  SHOULD+ be use= d'
> will do much to help this particular case.

I would actually be recommending min value of SHOULD - as it will not=
be recommended in a few years and is on a decline.  SHOULD + typically<= br> indicates that it will be required as a MUST next, whereas in this
case, it will be deprecated in a few years.

Thanks,
Kathleen

>
>         -- Mark



--

Best regards,
Kathleen

= --Apple-Mail-296DF410-C223-4BA5-9F78-27D1B9CD2D59-- From nobody Sat Sep 16 03: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 625FB132705; Sat, 16 Sep 2017 03:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 WK-0BWqvaCDe; Sat, 16 Sep 2017 03:46:12 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7995124B18; Sat, 16 Sep 2017 03:46:11 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id k9so4387166lfe.10; Sat, 16 Sep 2017 03:46:11 -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=f+mJlVs0m9hEQHa33qlm0EsEtm9da8dk2ABHyov8y3g=; b=DTfBEgE6P7qWKMCOWfzzEPOo0oi9uA3+ocZeAA4o6RU+m0zeWnvDh1vjZ5J2zFS5zM 3yBIb5MTSt3Fx8R+nvQG/aLb+/XmUeCPurTQFfooA/qTLqx9RYZLGgWgvxADA7Ilb4/l fWCb+LBRdHEYTO24tshmcnw5YoDzmFKVHeLI/mM0/hrpbKwpq0xaVWCnqRHDczNAHTAl 4fsXXNJg0v4DbhUSjHZLuSnEYjG4p15g/ybmAdmfx4L6rWuY938oSI9L4U+j2Y8u4j6q Cp9F8Mhpo5LjhbgwIgKpE4/Po9kMLFvdBDCOMPNJ0nsd2osAuF4cFwYCeMVeAL3KCx/X XY7w== 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=f+mJlVs0m9hEQHa33qlm0EsEtm9da8dk2ABHyov8y3g=; b=VIYip1MjS+ZZ4c16dcxEaL4QWgsNMaPABqPMHH2+pg0uEms/kBCJntFagwfXloRkwO rOwWEj74ZGLreEDNVZTVc5JezhJ8P89vXAsrFG8Ku+trGEOW+QMHnFvKAG7EtsQSDylY dhzNlwedF1NT8057nrmlan/MEDGbCFQcqZaaCnAgLdbu07IZQePDoTA2akPSUtENHWZf YvBKXwzf15DFv+zZ5OfSizu9V6RVhXXCXAxUXsUau8QXlhvFhYuPWbzqFlah5HFlu8JU 2l2L4tHE0RgU9gUxqoCUUZHBt1CJm3Djxs1I98k+lebd7qsiGSErU9V2Pq92g/oig5HF Ln6Q== X-Gm-Message-State: AHPjjUh46VGjLE0UX1nHsRcLECrRZ5zslzsWFVn/A34DnPJYB7kXHQuT sqLLBt64SFSc/ss8R7+tsKw6aM/kjjd/cpdfimw= X-Google-Smtp-Source: AOwi7QBpmEZd3yDnWsFPYLwm+XupLqCQRQDianvpRiLK7Hmk8mXFSzAtu7WmEhQ0fFnnvH9HEiAYtNqV8TWvH4SKs20= X-Received: by 10.46.93.215 with SMTP id v84mr3992069lje.8.1505558770203; Sat, 16 Sep 2017 03:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Sat, 16 Sep 2017 03:46:09 -0700 (PDT) In-Reply-To: <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> References: <150532612778.30489.12003202456500621755.idtracker@ietfa.amsl.com> <7EAB674F-C7F9-41B1-B362-721F47B86914@gmail.com> <8D12EBA0-06FE-499E-BD29-ED83D30FA02B@akamai.com> From: denis bider Date: Sat, 16 Sep 2017 04:46:09 -0600 Message-ID: To: "Salz, Rich" Cc: Kathleen Moriarty , curdle , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Daniel Migault , Loganaden Velvindron , Spencer Dawkins at IETF , The IESG Content-Type: multipart/alternative; boundary="001a114a0ac0afc01a05594c3752" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Sep 2017 10:46:14 -0000 --001a114a0ac0afc01a05594c3752 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Mark has a more educated position on this than I do, but I can respond to the following with a bit of practical information: > Next, what's the explicit compatibility concern? If your just waiting on a key rollover > or something along those lines, it's fine for this RFC to draw a hard line. One of the explicit compatibility concerns goes like this. More or less directly taken from a real example: - Organization X has a bunch of appliances (routers, etc) of model C. - The appliances need to back up their log files. - The appliances offer like two choices for backup, either plaintext FTP or some old version of SSH+SFTP with only 1024-bit crypto, or only SHA-1, or like that. - The manufacturer no longer maintains the appliances. There are no updates planned for SSH+SFTP on this hardware. - Organization X wants to upgrade their SSH+SFTP server S on which they receive the log files from the appliances. Now the issue arises that a new RFC is out that says "MUST NOT support 1024-bit crypto" or "MUST NOT support SHA-1". If it said "SHOULD NOT", then that's fine. Server S can come with 1024-bit crypto and SHA-1 disabled by default, but users can enable if they want compatibility with these old appliances. But the spec says "MUST NOT". So now Server S, if it wants to be compliant, cannot include 1024-bit crypto or SHA-1 at all. So now organization X cannot update to a new version of server S because then they won't be able to receive transfers from appliances that only support 1024-bit crypto or SHA-1 or whatnot. The organization is not throwing away the appliances also, because they serve their purpose and are a big hardware investment. So as a result, causal process goes like this: idealist standards organization says "MUST NOT" support old stuff =3D> new version of software cuts out support for old stuff =3D> new version can't interoperate with old hardware =3D> users don't upgrade to new version Or alternately: idealist standards organization says "MUST NOT" support old stuff =3D> new version of software violates spec and supports it anyway =3D> spec is toothless Or alternately: =3D> new version of software violates spec and supports "MUST NOT" algorith= ms anyway =3D> another type of user comes in and says "we can't use because you viola= te spec" =3D> two new versions of software must be released and maintained, one that violates spec and one that doesn't We must accept that hardware implementations exist which are set in stone. "MUST NOT" for anything that was enabled by default, in new software, in the last 10 years, is more or less a no-go. With regard to key rollover, most users do not rollover keys in SSH. At all= . On Fri, Sep 15, 2017 at 10:28 AM, Salz, Rich wrote: > =E2=9E=A2 Ok, so why can't that just be done the next time the deployed b= ase is > ready? Is there a reason why the deployed base needs to be compliant wit= h > this RFC? Or will making 2048 a MUST help to drive the change? > > > That=E2=80=99s an excellent question; I think Dennis and other authors sh= ould > reply =E2=98=BA > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114a0ac0afc01a05594c3752 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Mark has a more educated position on this than I d= o, but I can respond to the following with a bit of practical information:<= div>
>=C2=A0Next, what= 9;s the explicit compatibility concern?=C2=A0 If your just waiting on a key= rollover
> or somethi= ng along those lines, it's fine for this RFC to draw a hard line.

One of the explicit compatibility concerns goes li= ke this. More or less directly taken from a real example:
=
- Organization X has a bunch of appliances (routers, etc) of m= odel C.
- The appliances = need to back up their log files.
- The appliances offer like two choices for backup, either plaintex= t FTP or some old version of SSH+SFTP with only 1024-bit crypto, or only SH= A-1, or like that.
- The = manufacturer no longer maintains the appliances. There are no updates plann= ed for SSH+SFTP on this hardware.
- Organization X wants to upgrade their SSH+SFTP server S on which= they receive the log files from the appliances.

Now the issue arises that a new RFC = is out that says "MUST NOT support 1024-bit crypto" or "MUST= NOT support SHA-1".

If it said "SH= OULD NOT", then that's fine. Server S can come with 1024-bit crypt= o and SHA-1 disabled by default, but users can enable if they want compatib= ility with these old appliances.

But the spec= says "MUST NOT". So now Server S, if it wants to be compliant, c= annot include 1024-bit crypto or SHA-1 at all. So now organization X cannot= update to a new version of server S because then they won't be able to= receive transfers from appliances that only support 1024-bit crypto or SHA= -1 or whatnot.

The organization is not throwi= ng away the appliances also, because they serve their purpose and are a big= hardware investment. So as a result, causal process goes like this:=

idealist standards organization says "MUST NOT= " support old stuff
= =3D> new version of software cuts out support for old stuff
=
=3D> new version can't interop= erate with old hardware
= =3D> users don't upgrade to new version

Or alternately:

idealist standards organiza= tion says "MUST NOT" support old stuff
=3D> new version of software violates spec and s= upports it anyway
=3D>= spec is toothless

Or alternately:

=3D> new version of software violates spec and sup= ports "MUST NOT" algorithms anyway
=3D> another type of user comes in and says "= we can't use because you violate spec"
=3D> two new versions of software must be release= d and maintained, one that violates spec and one that doesn't

We must accept that hardware implementations exist w= hich are set in stone. "MUST NOT" for anything that was enabled b= y default, in new software, in the last 10 years, is more or less a no-go.<= /div>

With regard to key rollover, most users do not rol= lover keys in SSH. At all.


On Fri, Sep 15, 2017 at 10:28 AM, Salz,= Rich <rsalz@akamai.com> wrote:
=E2=9E=A2 Ok, so why can't that just be done the next time the dep= loyed base is ready?=C2=A0 Is there a reason why the deployed base needs to= be compliant with this RFC?=C2=A0 Or will making 2048 a MUST help to drive= the change?


That=E2=80=99s an excellent question; I think Dennis and other authors shou= ld reply =E2=98=BA

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

--001a114a0ac0afc01a05594c3752-- From nobody Mon Sep 18 14:03: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 A9F6D1241F3; Mon, 18 Sep 2017 14:02: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.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150576857465.15620.13860124894362383912@ietfa.amsl.com> Date: Mon, 18 Sep 2017 14:02:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-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: Mon, 18 Sep 2017 21:02: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 WG 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-05.txt Pages : 9 Date : 2017-09-18 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 Historic 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 18 14:05: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 0BB20132D89 for ; Mon, 18 Sep 2017 14:05:42 -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 5o8P_mqcjFOU for ; Mon, 18 Sep 2017 14:05:40 -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 734A2132397 for ; Mon, 18 Sep 2017 14:05:40 -0700 (PDT) X-AuditID: 1209190e-f83ff700000054a8-55-59c03509544d 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 0C.76.21672.90530C95; Mon, 18 Sep 2017 17:05: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 v8IL5Cg2031646 for ; Mon, 18 Sep 2017 17:05:13 -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 v8IL59ku012918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Sep 2017 17:05:12 -0400 Date: Mon, 18 Sep 2017 16:05:09 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170918210422.GJ96685@kduck.kaduk.org> References: <150576857465.15620.13860124894362383912@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150576857465.15620.13860124894362383912@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUixG6nrstpeiDSYPV9GYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49jPO8wF2/kr2jY0sjQwTuHpYuTkkBAwkZi7ZwljFyMXh5DA YiaJt5vPMoMkhASOM0qs2BEHkXjNJPHjw342kASLgKrEvq8/mUBsNgEViYbuy0ANHBwiAsIS PQskQcLCAiESny//A5vDC7Tg3eOtjBAzXSQmn/nDBhEXlDg58wkLiM0soCVx499LJpAxzALS Esv/cYCEOQVcJdZO6AQrFxVQlpi3bxXbBEb+WUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqy bnFyYl5eapGusV5uZoleakrpJkZQ2HFK8u1gnNTgfYhRgINRiYdX4Nr+SCHWxLLiytxDjJIc TEqivKKRQCG+pPyUyozE4oz4otKc1OJDjBIczEoivMnyByKFeFMSK6tSi/JhUtIcLErivNuC dkUKCaQnlqRmp6YWpBbBZGU4OJQkeI8bAzUKFqWmp1akZeaUIKSZODhBhvMADV8EUsNbXJCY W5yZDpE/xagoJc4bCpIQAElklObB9YLSgkT2/ppXjOJArwjzfgWp4gGmFLjuV0CDmYAGt+zY AzK4JBEhJdXAuONenmtpidGGnw6v3OKi90xOnVPNf2e3/JFD30OepV16efLIulDnMIllJetl Dt1ckO9+zKXhtU7Gy9cfDPL2LXSVXCLZELrUg+tn155pffM15snPWD3drO/ovizTRTIv05f8 5I8TXCGr6XJLg6HRYblG8uttHzojOVbxHVl1xtKxf9OXb/PXWiqxFGckGmoxFxUnAgD/jhXy 5gIAAA== Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-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, 18 Sep 2017 21:05:42 -0000 This version has updates prompted by IESG review. Hopefully it will suffice for Mirja to clear her DISCUSS. -Ben On Mon, Sep 18, 2017 at 02:02:54PM -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 WG 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-05.txt > Pages : 9 > Date : 2017-09-18 > > 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 > Historic 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-05 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Sep 20 09:34: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 C367313319E; Wed, 20 Sep 2017 09:34:22 -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_PASS=-0.001] autolearn=unavailable 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 u-PcI0zDjMWA; Wed, 20 Sep 2017 09:34:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB8813420B; Wed, 20 Sep 2017 09:28:54 -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=e1eBaT0HclULuf4S6bhJqHXVjK6uxp4zDZVjl/aIsXw=; b=Mwai4iB7UAamPzEAW+TiGGQpywMpZh4OAFMWCRYXXeqk4MtySup+gI7vfbNGNzU8yptD0wnTAH+XBClO/wm9qivmDjP7KafNqTJX9oCuQIvP5GReHC07yBeJZ83hikycgFkmT6xK4n+RJbZvJkT8K+liI7+SxbsMJvxn9kns/Ug= Received: from SN1PR05CA0034.namprd05.prod.outlook.com (10.163.68.172) by CY4PR05MB3605.namprd05.prod.outlook.com (10.171.244.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 16:28:53 +0000 Received: from BY2NAM05FT063.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by SN1PR05CA0034.outlook.office365.com (2a01:111:e400:5197::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5 via Frontend Transport; Wed, 20 Sep 2017 16:28:53 +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 BY2NAM05FT063.mail.protection.outlook.com (10.152.100.200) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Wed, 20 Sep 2017 16:28:52 +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, 20 Sep 2017 09:28:01 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v8KGRxUi008525; Wed, 20 Sep 2017 09:28:00 -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 6F9761144E; Wed, 20 Sep 2017 09:27:59 -0700 (PDT) To: Kathleen Moriarty CC: "Salz, Rich" , Spencer Dawkins at IETF , Loganaden Velvindron , draft-ietf-curdle-ssh-dh-group-exchange , curdle , curdle , The IESG , Daniel Migault In-Reply-To: References: Comments: In-reply-to: Kathleen Moriarty message dated "Fri, 15 Sep 2017 16:41:38 -0400." From: "Mark D. Baushke" Date: Wed, 20 Sep 2017 09:27:59 -0700 Message-ID: <21187.1505924879@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)(346002)(376002)(2980300002)(189002)(199003)(5003940100001)(8936002)(2950100002)(47776003)(6916009)(189998001)(4743002)(97876018)(81166006)(81156014)(356003)(54906003)(16586007)(8676002)(316002)(86362001)(6246003)(50466002)(76176999)(50986999)(53936002)(54356999)(68736007)(7696004)(48376002)(117636001)(305945005)(5660300001)(2810700001)(7126002)(229853002)(55016002)(106466001)(105596002)(76506005)(2906002)(53416004)(4326008)(39060400002)(230783001)(6392003)(69596002)(7846003)(6266002)(77096006)(97736004)(478600001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3605; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT063; 1:kGuW/oef1hrwTo909B0CcwmddEmKdwbOvkWLwqGVASMLwZcA6tfXYAG+ysCjKJOrXFZ7e/E+ggqxltHxZxY57+61GlxekJxuVMz8f4hOLeyBoR865X0gffExYm2rhk6g X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2f28a345-fc4e-42b9-b029-08d50044aea6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR05MB3605; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 3:VPU6dUVQMvQzmwVrTlJevEvH/i8P7o7dzbvUIO8gymaOpsTOm4nWsnU+k7dhBa+q39TrfCr15wKskQYchaC382XOPLSm6mXPRGSG0QmDFxsGbK9VSVCkevfzHMJgFXrm5ZaTLHvNark3O95KGXD6VI/2lvi/jLY/wL7PeE79t5B/6XU+x53JaZAyaczvsus8O2+RnYgkLMuabsNAbw+/zeLufErObzqnFjoWXtBdIseBEgbjY16yklN739bOC1FxK1AVMqR4pPVAafHAHN58FoV/d9PAj6fMCLGgfaZW7AiZL4Tc3jpW2jN09Qpi2X6X5UF6hpMbrJZwsKuGdZ4P3cEkfvzRCSWmcLjoKm3fbUU=; 25:6c8pOlAhv8lTq/Hr56ycDVYrOFoiAuQ2PNy0HKEdUSn2ro8i8rPMXvoqaoD3hHxQ9x9pv3GNXoYjmmvNJvsLe7/Q6V6oKQz7R6MIl8DywMdB2//4KnSL8gcbXbm5Lytm/gp0ijCu08j2mVisJQ0AqpPV1uCCyWI6EYNL0wygM+bl/wKsRjAm5RMUAAh2iN56/2Db1Fc16oESW2ymgtvafBU0ZoVm9FzwaxV1MfJ9klqs0x0G1w4qnWF9GzUtMqw4NGRhTXPGFSdE9dzAefmX/aXk1TeU2WGKCgkj9cIycUZk+RKHkmrfVBFZt3wxT21mFNlFZLnClgplErMslAICIw== X-MS-TrafficTypeDiagnostic: CY4PR05MB3605: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 31:NLJi6FKpS7ODnAf9xkdLdLzdqiPKHXulzKHnJJwRtCYhPQLMcrn0adYnPiGSwGNCePheNYKxsJHnc2SfYj3n6659cUg+Aek9fV7nqXq4ciqYmzuHpyNv1DCnk42XuUis5QFukExw13VweRJ7sSDK+yj+ZfjvbXfjCiEHxwleN1VjUXxaHnVCJyFERHh6UD5fUAgGDUT7nhWgD31L+Dv5mkHyROmz1m0V8BtD0moJBoM=; 20:6U/C6eIU+ferb/NDudxpVXLropcWZSYuwNeqTvpgxBQARHhBVf0Ag0VrMZ4HB6jNcYsWV/BM4UBzw1T36aq99Vtai0GGggcj5WY8MahhIff/4oauGm+Xt27DC9DAQrbhYpXTgRCv+RQzzvAE4Dyfbkv1qIao5Kqk4OofdsESB8+01fg24s9BEIGGT5LdCnRWoHhUvhiQFiru9q0/SR2mq0YOd6oWr+vkJgjmYAZgo6OrQN66h0wBPKJq4sQZt/WAHttypFki86UbN3Bua1hU8pcjxfzwuMai21+/h+oqHGhXjE1V/O3MeF78r3tzw4BMGGEJcK1foIpUQmdFWUBKQ42aMrz88D7s4kB1rDCOw4D9zd9gkcr572/6z2M4JoFI7rOf8xs7dvFdfwXCl+VJcuZsSt8YdbETbujNER3yc8qevs0HxXEdcEdPmLBnRjZp6p4qNtjhv0V1qd6rxQu5r/HGY2KNMllHAGzObiNO87mpGhwPzJecm06h/i5gXc0T X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93003095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3605; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3605; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 4:oaaqeSuPbU1kriAQUvzYpeIZipQbMnlBYIgmPvTPrMTrmXgZvIOpB6T6GSel7o/J1WU+bxnPyTum9ok06GMZOiWL/nRh9IvnG+90bbrGc/WKN25kHO1FzlMcYpWyBSiluV9wfEii9NTcY6iBjOO2tVuDdu5nembgV/Pjgmc3f6Gqxe0FDliHSIEOOajv6O2ppwRAwbYPcgZknnCnzsoAqhW0mM4wQ8d6ryEwYX8ssoRm9uQ8kWrICOl9wvsVcCmo X-Forefront-PRVS: 04362AC73B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3605; 23:p9YTV03CBhgcQ9CVoAsIOcUt3YoanCrTe5adZmB/Y?= =?us-ascii?Q?so2ZEqWuWFUovkW8sPiyH89+TzZ05CFGxNcrWohOkkdKxRfu7kpbTDxISQg7?= =?us-ascii?Q?JycZVu6wMLMfhlmM6Ndf3wpkpy8X+m83aTKtRERSnX4LdKbtn1QkCGRbPUeT?= =?us-ascii?Q?EIA/HoQGx88HmlgKYKHtGx636PUDfdwNWuNXzfqP+fqggZ7T98ZO1L6/5rVL?= =?us-ascii?Q?uZcW0+7O0KXHOJWBYXFEAwwi1I29CS9j8DmUPBOAy/6MrU0PF4Amg1Su6U8/?= =?us-ascii?Q?h+YIRtQ4p7kLTQzIQodijSpGI/tu6pqoeEUUoqunvFtNeXK5J4LHYAhOTvrg?= =?us-ascii?Q?sr5i/IIfu4K6uNg7NE2K9q/E/CaH8EvvCpraxKh7h9N+8GdcH5fmLan0Wyo3?= =?us-ascii?Q?8egTbZ/6d3HS7HvSglCUkKb7rE1JHTw39ej7qh2BylifTCXUomf99dI7IaFl?= =?us-ascii?Q?6uhujhX2shpAp5V2WbWNnhfttK0dhiF48csCzSPLbUM3jT4ARhRKLuhu+7wF?= =?us-ascii?Q?sBYsQmNcux+5cST4Ddw1rRqEbLlsSMof3HIdMqicftU8C74Ux1WhEpiTpVIr?= =?us-ascii?Q?8uJg/TPlN2ncJKl0ObG/OWXKpkCscEyrAyx8kz0uZ6rcveX/abaaCfRc6pXf?= =?us-ascii?Q?voVU0v1uuvg95i9rSTQ1n7XbhsNIP03AG1THzDP5tnvuSnKEs+mc+aiCWGSS?= =?us-ascii?Q?KG6x75UVYmzbJKqMJ1ysIAGUHJfFiiIkvdBXL1IiQu47VCw65wMc2MG4LFGs?= =?us-ascii?Q?ZnVeQvaUwWXfzaqb870zPyiCBfqcQQI0P6ZLag4XutdtZFIcc44Z+XR8eQxa?= =?us-ascii?Q?yQwMT8+1g6haGpYhsEqGhXTFsBAEmqaMpX1xgd1m+w5InJOVF9e11T9zQoDj?= =?us-ascii?Q?Mx3UKniyj1Wzcz7nVpY+bQ5fSnkCx6oEGAt4O710qE7m6CpbSpikP2Pg/bxq?= =?us-ascii?Q?68LG7hHgXHbWnjJWCLWGMYiUrelqHKGq0F4bW4POqLzJ1Sw7ul7PB1Ah6+L1?= =?us-ascii?Q?6dvNAzK7Syvlomr11TUa0hQdeGm3C9LTuWk92Hsh0RjZTmIukrj1UbcoGxLz?= =?us-ascii?Q?o2K/3nV1Ls+NmBlNtYq1oks1GOOrc2Y8DT7BrJBr/GvyWXEa8urctl3XnmO9?= =?us-ascii?Q?/DCgRH40VlkCMeO8/osfmebAyTMz4Gbkg5sQwzNCYd0oxQ4+x4zKlVSCTxg6?= =?us-ascii?Q?KddNnWbWDgMnq2OXWgFy5B7qj1XYkQbf92j92R6uwcR+sD1qoxvnSF8Sm9Ay?= =?us-ascii?Q?tPv3ey1MbQsHnyY8NTVJC6ObTBY9OchVX3+19wCCwGUDmxrgQKjhxv7yPk6E?= =?us-ascii?B?UT09?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 6:hfqaBKu4YXjg9qWY0pHvTSMmOqnFSLnDSPxTmUxPjtnisXh7gEdr+NGX1zvriejuro0cFeqyc0+6n8HM1ukzENijRZa0GKK7WuzEqjO7nJMOt2P/nBwXkS/ozfYmPrEufowkaJdv4YSqB0YnOlR4w6/Vkz+WdRYGelbx2uuDDwegDLL1WyK1B+etN2K6ldF3WxRRJwgQrwss9RTT9QtwLTxoLBdohCNZYNui7JcqZqFSsjrzwX0ZbNaFnCLyg/gkjtdgykR+7PAdvXCa8WTSF+82P5Ugv13d8yn2e+SIKgsCZK9AEUUKAxvUjMf5eXQsiya6kxuYLjlZKVP94oOMVw==; 5:bGQFGHMns8TY2bua7pSe8A3QG4PFQejPS1cz8JwVFcz9Qg8jcQPaFTY/hK2Wq3FasLF822L6gIh0DE/eRTQOyOuiSSCyGAVotHqiwYBaEVwT5sLyrIQzQ4uyUOVCaBJ7bqGY/1BqqzyDlEZUqOvg9Q==; 24:4KgbzRJFXg2gmC47jWI/ueG4As3kTo+iqiMkj+GbG2Mxq6QsTnzR3GldpE9Cff9bLp4xkhBC/sOK6mGlZttSCRScTyCA4QkBsohe5bkEmeA=; 7:L5HSMK7lPfJgTdyFx2kF8mhsXSXZVarVpuos1d3qGLf3XknMpwD9DLOlN51h9oW6nBqlNQfKU3ZFQtnMjJyrgkktzYx2etwe5Usy35IfWrD+ro5KVQE1I9VAEb/IMTji25/SkgjLeccWQL7SLJTOADbgWSy7PQThmPB2dO7UwWMUU1Soyxhs6r1YD/c0HB2+VQRTP0if29W2EJxiMtnHpMtZixLcThd77IrBQHfyqCY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 16:28:52.8541 (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: CY4PR05MB3605 Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 20 Sep 2017 16:34:23 -0000 Hi Kathleen, Aside: Regarding SHOULD+ and SHOULD- in IETF drafts... The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of that document defined and used SHOULD+ and SHOULD-, but many reviewers did not like them. So, I removed them from the draft-ietf-curdle-ssh-kex-sha2-09.txt edition. Regarding the language in the current draft... The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is Loganaden Velvindron. I believe that he is the one who should make any changes to the document to address comments provided in this review process. I have no objections to suggesting that MIN value SHOULD be 2048 and that n SHOULD be 3072 or be capable of being set to 3072 by an implementation as 2048 is not expected to need to be updated within the next five years, perhaps abruptly. I actually think that this would be a good idea. Does this make sense to anyone else? Thanks, -- Mark From nobody Fri Sep 22 06:35: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 BBB901342E8 for ; Fri, 22 Sep 2017 06:35:26 -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 AqKev9fD8O78 for ; Fri, 22 Sep 2017 06:35:25 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2511342DE for ; Fri, 22 Sep 2017 06:35:24 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i6so742975ywc.9 for ; Fri, 22 Sep 2017 06:35:24 -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=6oXgOp7PVxPO7SOVALoCzRoUGq5pjDmizWBaN0gmTRo=; b=vEJ4eRsg6nI+7poSVT/A1HmPDCiGe3Jw+pvocTYOES5b1TrdYd2FgJxIvMB8JGmUu/ RQb/5AZPoQTZuxjT7yfuwV0HI6FEUbBj23K5ZYtSzgKdgzOh92NtfUx/VCcCoTxvZuUU 6z4Uldv9ddHOYxStE6voeWqOUeApak3AoOZI8aF2GQOvADRyB9/I4iwOtVE4YzX2sGVE aj0SoTTi2xAe+QVN7FxhaqnYVtIJFyu7QYnJTNZ+dBOUBIEuoZZiywOO5oSytWoUNFjZ DHDs0G01sanXcfjworxZZKreJJy5bLu3O0QFsUkkzwEq/PTjcejGmrriiuHnI/bc2Cwp stWw== 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=6oXgOp7PVxPO7SOVALoCzRoUGq5pjDmizWBaN0gmTRo=; b=BI6vmmCR2BfBwNE7ZucvG5p40evqHDz3+dNSyCgd+mYeQe1V+hYmetYBOvo5scC1Kv Pa/bvmEc1cfBL330P+sA6osbvYodO3HPU3d62V/hzlWpAZJaCy7e+G3sCZi/voVjtPSH 6wq9NDvmCsWt6wsk8pXKByjYcSU3RAbVswM30FfaLWQDZazA84MYjpRgRzmaZjM81NDM it77e5hqjGCKU8uIyA/sBRIXxhFY+mg/w1mQqYXre0mHKY3fscO4ENJRHsuPBj6HKsDW bxH5uFXS2X0zLvEdiTAa88StAZlw7Ea4prytwgGEn0POXkpbBbP3IN1aHg8gIEtKyM/s W//A== X-Gm-Message-State: AHPjjUiTlu2xi1hA1QdtNEjidKM1MalE4YH9rGOkGDoLkZSVaYBCmWe9 lxsJWTf9yoGYQp0E6umYF8BI65Vayw0xg/G8dA2BUg== X-Google-Smtp-Source: AOwi7QDI9TlFTghL8zfNse6EWvK9fqUEuv1mHADNZwLbtaZzduXkspNmF8Vpw4erdduccUr/1dmEyB00qo2GtcSUge4= X-Received: by 10.37.206.136 with SMTP id x130mr3785489ybe.37.1506087324182; Fri, 22 Sep 2017 06:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.17 with HTTP; Fri, 22 Sep 2017 06:34:43 -0700 (PDT) In-Reply-To: <21187.1505924879@eng-mail01.juniper.net> References: <21187.1505924879@eng-mail01.juniper.net> From: Eric Rescorla Date: Fri, 22 Sep 2017 06:34:43 -0700 Message-ID: To: "Mark D. Baushke" Cc: Kathleen Moriarty , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Daniel Migault , Loganaden Velvindron , Spencer Dawkins at IETF , The IESG Content-Type: multipart/alternative; boundary="94eb2c1903a8f580ee0559c7477a" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 13:35:27 -0000 --94eb2c1903a8f580ee0559c7477a Content-Type: text/plain; charset="UTF-8" Chairs: do we expect Loganaden to make changes? -Ekr On Wed, Sep 20, 2017 at 9:27 AM, Mark D. Baushke wrote: > Hi Kathleen, > > Aside: Regarding SHOULD+ and SHOULD- in IETF drafts... > > The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of that document > defined and used SHOULD+ and SHOULD-, but many reviewers did not like > them. So, I removed them from the draft-ietf-curdle-ssh-kex- > sha2-09.txt > edition. > > Regarding the language in the current draft... > > The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is > Loganaden Velvindron. > > I believe that he is the one who should make any changes to the > document to address comments provided in this review process. > > I have no objections to suggesting that MIN value SHOULD be 2048 > and that n SHOULD be 3072 or be capable of being set to 3072 by > an implementation as 2048 is not expected to need to be updated > within the next five years, perhaps abruptly. I actually think > that this would be a good idea. > > Does this make sense to anyone else? > > Thanks, > -- Mark > > --94eb2c1903a8f580ee0559c7477a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chairs: do we expect Loganaden to make changes?
<= br>
-Ekr


On Wed, Sep 20,= 2017 at 9:27 AM, Mark D. Baushke <mdb@juniper.net> wrote:
=
Hi Kathleen,

Aside: Regarding SHOULD+ and SHOULD- in IETF drafts...

=C2=A0 =C2=A0 The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of tha= t document
=C2=A0 =C2=A0 defined and used SHOULD+ and SHOULD-, but many reviewers did = not like
=C2=A0 =C2=A0 them. So, I removed them from the draft-ietf-curdle-ssh-kex-<= wbr>sha2-09.txt
=C2=A0 =C2=A0 edition.

Regarding the language in the current draft...

The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is Loganaden Velvindron.

I believe that he is the one who should make any changes to the
document to address comments provided in this review process.

I have no objections to suggesting that MIN value SHOULD be 2048
and that n SHOULD be 3072 or be capable of being set to 3072 by
an implementation as 2048 is not expected to need to be updated
within the next five years, perhaps abruptly. I actually think
that this would be a good idea.

Does this make sense to anyone else?

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


--94eb2c1903a8f580ee0559c7477a-- From nobody Fri Sep 22 06:37:24 2017 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65AD132D51; Fri, 22 Sep 2017 06:37:16 -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 X8fkHJQoEDk8; Fri, 22 Sep 2017 06:37:13 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307AC13305E; Fri, 22 Sep 2017 06:37:13 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id 80so1174340lfy.4; Fri, 22 Sep 2017 06:37:13 -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=YSGUFig7hZJYoi8zvBTVfKT4/+hn2353Qj5Qwc4mHXc=; b=QKTiOFKAu6xHhJ2IRoAFuNr+Wsw9o/fbR2NzUGR/36s+n9uJvHhUkp3jSLoeolc9ve GyCGNt3wlBSgomzwQ88CuA//1+BWLTdsc10wj1fqv8S7QHbV+QsUlhDj59YCJ9pV/Aao dAJJ4LTlzibkrIYaz5xeQsInDnH1mgphuq3AB5qqx4L0ieJOLWUPMRG5D23mcqfQswqK HwoLN3hY11TeAivYjt4O6ohd02s45YMExZuBQty01u8dRCKjkwzRNf9KPUvGR6quNvWG vEZYb9vPCQiPasPtsSGwucq30HKvglskkIOBtFXhx3WPBN4lk/5N+s2NISRBgefHUmYH gXPg== 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=YSGUFig7hZJYoi8zvBTVfKT4/+hn2353Qj5Qwc4mHXc=; b=uRT/htbVZ6Gu3E09e8Kp7jc8GID4uAp0+ClEJQUsfw/Kpvzc8eO0HR9lyJt7zQfUFf ZcVe3Io9WuN72rcGLIfJCZBBpMuqBbqR30RwyLZ4G5jcD61p149DDckyS5lWLrNtgXCJ vJn7jOG4wv1f+T6xcapZMdkvftSoLArpBqYAFARy7WwVNi0TYNizwLjRI4aniFaf8PAX 8LMnn0gJoKjDm8FbSOY6NhJDpHPh/Xdy0e8yTBOD4LcuVYjCAzmIRznRsUYN9bi41+CW 9OYdJGajNqGl0ZtAz5JI0w6DaGZGGt1p1cEWfqlrW+iBDSSWgYn3r51yFd2PO3H6Ojlr zm7w== X-Gm-Message-State: AHPjjUiXaXUn8fqiLj32jF93F2QtI8Y9Q+dj18gHSq6XganK/8s5QARR sPQ4ptxVY2hy0+wsFcBEIPfLJtte36Fis8kVdTM= X-Google-Smtp-Source: AOwi7QBMVbnbb3dwPwHeyu0ybE9nj62A7pgo4vphSPVEfzH/w4igUL+yd8atnu6JL6jTzGqK8/kly8YOEXxxREFMyvw= X-Received: by 10.25.16.88 with SMTP id f85mr2119957lfi.1.1506087431182; Fri, 22 Sep 2017 06:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.29.135 with HTTP; Fri, 22 Sep 2017 06:37:10 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> From: Loganaden Velvindron Date: Fri, 22 Sep 2017 17:37:10 +0400 Message-ID: To: Eric Rescorla Cc: "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Daniel Migault , Loganaden Velvindron , Kathleen Moriarty , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 13:37:17 -0000 I am working on the requested changes. I will upload the new document soon. On Fri, Sep 22, 2017 at 5:34 PM, Eric Rescorla wrote: > Chairs: do we expect Loganaden to make changes? > > -Ekr > > > On Wed, Sep 20, 2017 at 9:27 AM, Mark D. Baushke wrote: >> >> Hi Kathleen, >> >> Aside: Regarding SHOULD+ and SHOULD- in IETF drafts... >> >> The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of that document >> defined and used SHOULD+ and SHOULD-, but many reviewers did not like >> them. So, I removed them from the >> draft-ietf-curdle-ssh-kex-sha2-09.txt >> edition. >> >> Regarding the language in the current draft... >> >> The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is >> Loganaden Velvindron. >> >> I believe that he is the one who should make any changes to the >> document to address comments provided in this review process. >> >> I have no objections to suggesting that MIN value SHOULD be 2048 >> and that n SHOULD be 3072 or be capable of being set to 3072 by >> an implementation as 2048 is not expected to need to be updated >> within the next five years, perhaps abruptly. I actually think >> that this would be a good idea. >> >> Does this make sense to anyone else? >> >> Thanks, >> -- Mark >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Fri Sep 22 06:38: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 4374313305E; Fri, 22 Sep 2017 06:38:09 -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 aietcV9TAgpV; Fri, 22 Sep 2017 06:38:06 -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 D6728132403; Fri, 22 Sep 2017 06:38:05 -0700 (PDT) X-AuditID: c6180641-0f7ff70000002d27-30-59c4cbd9c3e5 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 59.ED.11559.9DBC4C95; Fri, 22 Sep 2017 10:37:45 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0352.000; Fri, 22 Sep 2017 09:38:04 -0400 From: Daniel Migault To: Eric Rescorla , "Mark D. Baushke" CC: curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Loganaden Velvindron , "Kathleen Moriarty" , Spencer Dawkins at IETF , The IESG Thread-Topic: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) Thread-Index: AQHTM6esOe9Y0SuI2Ee0m8dsiS+0KKLA6HbQ Date: Fri, 22 Sep 2017 13:38:03 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> References: <21187.1505924879@eng-mail01.juniper.net> 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_2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyuXRPiO7N00ciDZYckbeY2bOB2WLrwlnM Fv/2r2a1WPH6HLvFjD8TmS0aduZbfJ04n9Wi6851Nov/WzpZLJZN2cPswOUx+cgCZo+ds+6y e+zdtojVY8mSn0we15uusntMftzGHMAWxWWTkpqTWZZapG+XwJWxcNkSloJT/hWHjuo2MG7w 7WLk5JAQMJH48+cEK4gtJHCUUWLD1+ouRi4gezmjxMVjM5hAEmwCRhJth/rZQWwRAVeJ2etu soAUMQv8YJL4Mu8qWLewQK7EmhezGCGK8iS2nOgHauYAso0k1u2RAQmzCKhKTLu8nhnE5hXw lVjZvpcRYtlhRonpKz+DzeEUCJQ4fegs2BxGATGJ76fWgB3BLCAucevJfCaIqwUkluw5zwxh i0q8fPyPFcJWkvj4ez47RH2+xOPWD1DLBCVOznzCMoFRZBaSUbOQlM1CUjYL6GxmAU2J9bv0 IUoUJaZ0P2SHsDUkWufMZUcWX8DIvoqRo7S4ICc33chwEyMwYo9JsDnuYNzb63mIUYCDUYmH d9m6I5FCrIllxZW5hxglOJiVRHiP/gMK8aYkVlalFuXHF5XmpBYfYpTmYFES531XfiFCSCA9 sSQ1OzW1ILUIJsvEwSnVwLhN0CukIm7PVHk9+0dXrjS9uLoxzypLy83pbZGvheDpaxtcd/GK 8sVs6dTO2PO/gMH498bVF/V54v/sCb/1505d9P6dv0oTT1rF2rc9vrR2V7LzDt4vygzJh5bN +ZzGZ3fx5tYLzfIuV6vn/lXkzZUN/8Cdufb/r8Uyj/3uMD/ZcEWmclbAXjUlluKMREMt5qLi RAAG5WKP1AIAAA== Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 13:38:09 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBzdXJlIGhlIHdpbGwuDQpZb3VycywNCkRhbmllbA0KDQpGcm9tOiBDdXJkbGUgW21haWx0 bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIyLCAyMDE3IDk6MzUgQU0NClRvOiBNYXJrIEQuIEJhdXNo a2UgPG1kYkBqdW5pcGVyLm5ldD4NCkNjOiBjdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz47IFNhbHos IFJpY2ggPHJzYWx6QGFrYW1haS5jb20+OyBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZGgtZ3JvdXAt ZXhjaGFuZ2UgPGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1kaC1ncm91cC1leGNoYW5nZUBpZXRmLm9y Zz47IGN1cmRsZSA8Y3VyZGxlLWNoYWlyc0BpZXRmLm9yZz47IERhbmllbCBNaWdhdWx0IDxkYW5p ZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+OyBMb2dhbmFkZW4gVmVsdmluZHJvbiA8bG9nYW5AaGFj a2Vycy5tdT47IEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbT47IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDdXJkbGVdIEth dGhsZWVuIE1vcmlhcnR5J3MgWWVzIG9uIGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1kaC1ncm91cC1l eGNoYW5nZS0wNTogKHdpdGggQ09NTUVOVCkNCg0KQ2hhaXJzOiBkbyB3ZSBleHBlY3QgTG9nYW5h ZGVuIHRvIG1ha2UgY2hhbmdlcz8NCg0KLUVrcg0KDQoNCk9uIFdlZCwgU2VwIDIwLCAyMDE3IGF0 IDk6MjcgQU0sIE1hcmsgRC4gQmF1c2hrZSA8bWRiQGp1bmlwZXIubmV0PG1haWx0bzptZGJAanVu aXBlci5uZXQ+PiB3cm90ZToNCkhpIEthdGhsZWVuLA0KDQpBc2lkZTogUmVnYXJkaW5nIFNIT1VM RCsgYW5kIFNIT1VMRC0gaW4gSUVURiBkcmFmdHMuLi4NCg0KICAgIFRoZSBkcmFmdC1pZXRmLWN1 cmRsZS1zc2gta2V4LXNoYTItMDgudHh0IGVkaXRpb24gb2YgdGhhdCBkb2N1bWVudA0KICAgIGRl ZmluZWQgYW5kIHVzZWQgU0hPVUxEKyBhbmQgU0hPVUxELSwgYnV0IG1hbnkgcmV2aWV3ZXJzIGRp ZCBub3QgbGlrZQ0KICAgIHRoZW0uIFNvLCBJIHJlbW92ZWQgdGhlbSBmcm9tIHRoZSBkcmFmdC1p ZXRmLWN1cmRsZS1zc2gta2V4LXNoYTItMDkudHh0DQogICAgZWRpdGlvbi4NCg0KUmVnYXJkaW5n IHRoZSBsYW5ndWFnZSBpbiB0aGUgY3VycmVudCBkcmFmdC4uLg0KDQpUaGUgcHJpbWFyeSBhdXRo b3Igb2YgZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWRoLWdyb3VwLWV4Y2hhbmdlLTA1IGlzDQpMb2dh bmFkZW4gVmVsdmluZHJvbi4NCg0KSSBiZWxpZXZlIHRoYXQgaGUgaXMgdGhlIG9uZSB3aG8gc2hv dWxkIG1ha2UgYW55IGNoYW5nZXMgdG8gdGhlDQpkb2N1bWVudCB0byBhZGRyZXNzIGNvbW1lbnRz IHByb3ZpZGVkIGluIHRoaXMgcmV2aWV3IHByb2Nlc3MuDQoNCkkgaGF2ZSBubyBvYmplY3Rpb25z IHRvIHN1Z2dlc3RpbmcgdGhhdCBNSU4gdmFsdWUgU0hPVUxEIGJlIDIwNDgNCmFuZCB0aGF0IG4g U0hPVUxEIGJlIDMwNzIgb3IgYmUgY2FwYWJsZSBvZiBiZWluZyBzZXQgdG8gMzA3MiBieQ0KYW4g aW1wbGVtZW50YXRpb24gYXMgMjA0OCBpcyBub3QgZXhwZWN0ZWQgdG8gbmVlZCB0byBiZSB1cGRh dGVkDQp3aXRoaW4gdGhlIG5leHQgZml2ZSB5ZWFycywgcGVyaGFwcyBhYnJ1cHRseS4gSSBhY3R1 YWxseSB0aGluaw0KdGhhdCB0aGlzIHdvdWxkIGJlIGEgZ29vZCBpZGVhLg0KDQpEb2VzIHRoaXMg bWFrZSBzZW5zZSB0byBhbnlvbmUgZWxzZT8NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIC0t IE1hcmsNCg0K --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6eusaamb107erics_ 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 OyxzYW5zLXNlcmlmIj5JIGFtIHN1cmUgaGUgd2lsbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91cnMsDQo8YnI+DQpEYW5p ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEN1 cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDIyLCAy MDE3IDk6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgRC4gQmF1c2hrZSAmbHQ7bWRiQGp1bmlw ZXIubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gY3VyZGxlICZsdDtjdXJkbGVAaWV0Zi5vcmcmZ3Q7 OyBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0OzsgZHJhZnQtaWV0Zi1jdXJkbGUt c3NoLWRoLWdyb3VwLWV4Y2hhbmdlICZsdDtkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZGgtZ3JvdXAt ZXhjaGFuZ2VAaWV0Zi5vcmcmZ3Q7OyBjdXJkbGUgJmx0O2N1cmRsZS1jaGFpcnNAaWV0Zi5vcmcm Z3Q7OyBEYW5pZWwgTWlnYXVsdCAmbHQ7ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tJmd0Ozsg TG9nYW5hZGVuIFZlbHZpbmRyb24NCiAmbHQ7bG9nYW5AaGFja2Vycy5tdSZndDs7IEthdGhsZWVu IE1vcmlhcnR5ICZsdDtrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSZndDs7IFNwZW5j ZXIgRGF3a2lucyBhdCBJRVRGICZsdDtzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSZndDs7 IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0N1cmRsZV0gS2F0aGxlZW4gTW9yaWFydHkncyBZZXMgb24gZHJhZnQtaWV0Zi1jdXJkbGUtc3No LWRoLWdyb3VwLWV4Y2hhbmdlLTA1OiAod2l0aCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlyczogZG8gd2UgZXhwZWN0IExvZ2FuYWRlbiB0byBtYWtl IGNoYW5nZXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBT ZXAgMjAsIDIwMTcgYXQgOToyNyBBTSwgTWFyayBELiBCYXVzaGtlICZsdDs8YSBocmVmPSJtYWls dG86bWRiQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWRiQGp1bmlwZXIubmV0PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBLYXRobGVlbiw8YnI+DQo8YnI+DQpB c2lkZTogUmVnYXJkaW5nIFNIT1VMRCYjNDM7IGFuZCBTSE9VTEQtIGluIElFVEYgZHJhZnRzLi4u PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWtleC1z aGEyLTA4LnR4dCBlZGl0aW9uIG9mIHRoYXQgZG9jdW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7IGRl ZmluZWQgYW5kIHVzZWQgU0hPVUxEJiM0MzsgYW5kIFNIT1VMRC0sIGJ1dCBtYW55IHJldmlld2Vy cyBkaWQgbm90IGxpa2U8YnI+DQombmJzcDsgJm5ic3A7IHRoZW0uIFNvLCBJIHJlbW92ZWQgdGhl bSBmcm9tIHRoZSBkcmFmdC1pZXRmLWN1cmRsZS1zc2gta2V4LXNoYTItMDkudHh0PGJyPg0KJm5i c3A7ICZuYnNwOyBlZGl0aW9uLjxicj4NCjxicj4NClJlZ2FyZGluZyB0aGUgbGFuZ3VhZ2UgaW4g dGhlIGN1cnJlbnQgZHJhZnQuLi48YnI+DQo8YnI+DQpUaGUgcHJpbWFyeSBhdXRob3Igb2YgZHJh ZnQtaWV0Zi1jdXJkbGUtc3NoLWRoLWdyb3VwLWV4Y2hhbmdlLTA1IGlzPGJyPg0KTG9nYW5hZGVu IFZlbHZpbmRyb24uPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoYXQgaGUgaXMgdGhlIG9uZSB3aG8g c2hvdWxkIG1ha2UgYW55IGNoYW5nZXMgdG8gdGhlPGJyPg0KZG9jdW1lbnQgdG8gYWRkcmVzcyBj b21tZW50cyBwcm92aWRlZCBpbiB0aGlzIHJldmlldyBwcm9jZXNzLjxicj4NCjxicj4NCkkgaGF2 ZSBubyBvYmplY3Rpb25zIHRvIHN1Z2dlc3RpbmcgdGhhdCBNSU4gdmFsdWUgU0hPVUxEIGJlIDIw NDg8YnI+DQphbmQgdGhhdCBuIFNIT1VMRCBiZSAzMDcyIG9yIGJlIGNhcGFibGUgb2YgYmVpbmcg c2V0IHRvIDMwNzIgYnk8YnI+DQphbiBpbXBsZW1lbnRhdGlvbiBhcyAyMDQ4IGlzIG5vdCBleHBl Y3RlZCB0byBuZWVkIHRvIGJlIHVwZGF0ZWQ8YnI+DQp3aXRoaW4gdGhlIG5leHQgZml2ZSB5ZWFy cywgcGVyaGFwcyBhYnJ1cHRseS4gSSBhY3R1YWxseSB0aGluazxicj4NCnRoYXQgdGhpcyB3b3Vs ZCBiZSBhIGdvb2QgaWRlYS48YnI+DQo8YnI+DQpEb2VzIHRoaXMgbWFrZSBzZW5zZSB0byBhbnlv bmUgZWxzZT88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBNYXJrPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6eusaamb107erics_-- From nobody Fri Sep 22 06:52: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 2477D1342EB for ; Fri, 22 Sep 2017 06:52:38 -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=unavailable 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 bHjLawzwE9jl for ; Fri, 22 Sep 2017 06:52:35 -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 A61641342F0 for ; Fri, 22 Sep 2017 06:52:35 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id s62so781093ywg.0 for ; Fri, 22 Sep 2017 06:52:35 -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=T18A4vmDinXdSW7vXkqCjRVXQn3sEMCDv4+kF24Ggbs=; b=J5yFeCnkeOyE6TSU+2+YZ3z9zGYA8aNtWv87W7AbK/Qh1SF2RcuDx/L59oQKp7+gLg +rUtSE+2W6ECNGmBv+Rk+3oMUnYjBFsy3h+bZA0tEdIsYGgcltXW5yE3Fhbny2Af8vaS dAiW7uUwe0Mn0307u8QamEhJjE32UCk0AmpggR2XsdsGtldRsuW+OpzABGtNV82aXxgy k6tLVEcPgYGzNhte0n7Fm2Yy92wCIAh0z2zM6Abq6MVoCXLy0vDKacN4b+m0WQv8nAMw eeLioUAmiY6jYLIffYRTsqxmft7WcTdarQ3lZ2UujB44hLlKkvczT5k/b/nNP9cE+G10 b68A== 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=T18A4vmDinXdSW7vXkqCjRVXQn3sEMCDv4+kF24Ggbs=; b=YrPVptdSaV1O11xj5XxHelHBoi4c8sT3kC+mMNzTyQCDRslLLRuZRf4+Bcq23QveEZ eQEBU/6o5xUaU8lIh1mU4to04prHVWcmwoJRRsfJo0faf4fxaNqc//d0T85Ghw0Yh4GK JyRbovh/tccSXdp8RCZQogLo4JfU3uXGO+JQyNO4HSIGEupuzoZztenUHB3CyatU2NLt 3p+TmrSB6Ke4Gs7x7aI7l5V2MGJpoaNh2PJe+1SD8qZnDSHmUix8xRtlNBo+1T+o/ht5 1O07jzi5NTDBk+hW3KrC0zS57QLjmOJ38NVKVGmLbQqUszP/EVCbWB12miII+bf67epX y1Cg== X-Gm-Message-State: AHPjjUiFb433dEHa6U7jd93OI2jX/28XAHGn+nKcn5UaAneWv93PiCzp DKKNP/yEIuL35ZVgup4FM8zBHwxNx3zgkT/8JscebQ== X-Google-Smtp-Source: AOwi7QARR5/yOA4V0uvoKXvlU8jUhkUZ17FscdPPgqP7JTB+LNaJDdoaEf88+dhpmM5TnkEI6O7wyqGstX/hHp13HRk= X-Received: by 10.129.121.76 with SMTP id u73mr2541488ywc.476.1506088354898; Fri, 22 Sep 2017 06:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.17 with HTTP; Fri, 22 Sep 2017 06:51:53 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Eric Rescorla Date: Fri, 22 Sep 2017 06:51:53 -0700 Message-ID: To: Daniel Migault Cc: "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Loganaden Velvindron , Kathleen Moriarty , Spencer Dawkins at IETF , The IESG Content-Type: multipart/alternative; boundary="94eb2c0a8aba6527fd0559c785ed" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 13:52:38 -0000 --94eb2c0a8aba6527fd0559c785ed Content-Type: text/plain; charset="UTF-8" Fantastic. I just hadn't heard from him yet and wanted to make sure we agreed on who had the job On Fri, Sep 22, 2017 at 6:38 AM, Daniel Migault wrote: > I am sure he will. > > Yours, > Daniel > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* Friday, September 22, 2017 9:35 AM > *To:* Mark D. Baushke > *Cc:* curdle ; Salz, Rich ; > draft-ietf-curdle-ssh-dh-group-exchange group-exchange@ietf.org>; curdle ; Daniel Migault > ; Loganaden Velvindron ; > Kathleen Moriarty ; Spencer Dawkins at > IETF ; The IESG > *Subject:* Re: [Curdle] Kathleen Moriarty's Yes on > draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) > > > > Chairs: do we expect Loganaden to make changes? > > > > -Ekr > > > > > > On Wed, Sep 20, 2017 at 9:27 AM, Mark D. Baushke wrote: > > Hi Kathleen, > > Aside: Regarding SHOULD+ and SHOULD- in IETF drafts... > > The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of that document > defined and used SHOULD+ and SHOULD-, but many reviewers did not like > them. So, I removed them from the draft-ietf-curdle-ssh-kex- > sha2-09.txt > edition. > > Regarding the language in the current draft... > > The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is > Loganaden Velvindron. > > I believe that he is the one who should make any changes to the > document to address comments provided in this review process. > > I have no objections to suggesting that MIN value SHOULD be 2048 > and that n SHOULD be 3072 or be capable of being set to 3072 by > an implementation as 2048 is not expected to need to be updated > within the next five years, perhaps abruptly. I actually think > that this would be a good idea. > > Does this make sense to anyone else? > > Thanks, > -- Mark > > > --94eb2c0a8aba6527fd0559c785ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fantastic. I just hadn't heard from him yet and wanted= to make sure we agreed on who had the job


On Fri, Sep 22, 2017 at 6:3= 8 AM, Daniel Migault <daniel.migault@ericsson.com>= wrote:

I am sure he will.

Yours,
Daniel

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.org<= /a>] On Behalf Of Eric Rescorla
Sent: Friday, September 22, 2017 9:35 AM
To: Mark D. Baushke <mdb@juniper.net>
Cc: curdle <= curdle@ietf.org>; Salz, Rich <rsalz@akamai.com>; draft-ietf-curdle-ssh-dh-= group-exchange <draft-ietf-curdle-ssh-dh-group-exchange@= ietf.org>; curdle <curdle-chairs@ietf.org>; Daniel Migault <daniel.migault@erics= son.com>; Loganaden Velvindron <logan@hackers.mu= >; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; S= pencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; The IESG <= ;iesg@ietf.org> Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curd= le-ssh-dh-group-exchange-05: (with COMMENT)

=C2=A0

Chairs: do we expect Loganaden to make changes?

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Wed, Sep 20, 2017 at 9:27 AM, Mark D. Baushke <= ;mdb@juniper.net&g= t; wrote:

Hi Kathleen,

Aside: Regarding SHOULD+ and SHOULD- in IETF drafts...

=C2=A0 =C2=A0 The draft-ietf-curdle-ssh-kex-sha2-08.txt edition of tha= t document
=C2=A0 =C2=A0 defined and used SHOULD+ and SHOULD-, but many reviewers did = not like
=C2=A0 =C2=A0 them. So, I removed them from the draft-ietf-curdle-ssh-kex-<= wbr>sha2-09.txt
=C2=A0 =C2=A0 edition.

Regarding the language in the current draft...

The primary author of draft-ietf-curdle-ssh-dh-group-exchange-05 is Loganaden Velvindron.

I believe that he is the one who should make any changes to the
document to address comments provided in this review process.

I have no objections to suggesting that MIN value SHOULD be 2048
and that n SHOULD be 3072 or be capable of being set to 3072 by
an implementation as 2048 is not expected to need to be updated
within the next five years, perhaps abruptly. I actually think
that this would be a good idea.

Does this make sense to anyone else?

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

=C2=A0


--94eb2c0a8aba6527fd0559c785ed-- From nobody Fri Sep 22 07: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 4A3F8134313 for ; Fri, 22 Sep 2017 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 Tmu_TmiTM33h for ; Fri, 22 Sep 2017 07:20:13 -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 BB65B1342EB for ; Fri, 22 Sep 2017 07:20:11 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id k101so3391153iod.0 for ; Fri, 22 Sep 2017 07:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HWEJ4AvnHiDZmxNTAUTatKUu7Gf6TCY0n+1F3rOKFRo=; b=UyLGZzsGk+WeqfRU/+EeJGWKhKJFhhaEHVpg6pqFUHW4KpUo0b/6E0rJb4zF9YI4Xv EmA1cDJe4J6d4AwOoh+vy0kll86EY+XzZUiHS67+C/x/Q7U+nI7X6ZsDqnrM/910xXec M8ZE0lVziD/vHQhDVmx59aU+LnAU7Ne7kyJGPq8YKpeIJx2hU0o9wVk82o6i7Qgi3W35 BEb6sF2j/MUziA9cLO9bMAbBdfdeem6nsNv5hc5B1QSYrSYgJBw7nsECT8svz5hOdIv7 Rjq7ucPkUxUcjZOqBvEmzJuJNg6vv/z8eOw8sOe77hWOdCO+Ghgwrjys5GbylfL56E3L 7IPA== 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=HWEJ4AvnHiDZmxNTAUTatKUu7Gf6TCY0n+1F3rOKFRo=; b=HLN4XnHIIeU9NKnSLV0LlXzaul+Pe1uM8zsjKf0ZbLjvbFExhyww9M6XoEBRV7TaHV 93nFEkKVDRUhcF6IFvRd765ZvcabtyfkBnWIOT1AgB6d2NAqpG7kmkc7yD5VBOIJxFYz JxuRTWUhOt0+HLDMGuJwIUcj4H22yFUXyN8GzoBYdEe3Me7Ar4lkNBQVL03+CD8ioemA QwlD1SEcFJ4xRw0Nxa+YfpmizRX/gtp2mSHL338d/KpgDxgQ30dmKkjOXr6p44nXM1Bc PmUPmFs2yPglWWiLYEGVe08LBr8Y0obdvbZ1j9i9pj0ZmZ0CQh3hMShNBEHC+2D+ffnv ay8Q== X-Gm-Message-State: AHPjjUgFASOkHnhqYul9B3IWGdC3Pya2OYQLT7ygJMD8Qjhzu3mYlPa0 AU2te4GfmHdfu6dsoZrZwxjuEkUbu55YxJplVBVnYA== X-Google-Smtp-Source: AOwi7QA5V1oUUK198RD2hI5PIpbm1skbVv4aVrIb5pHy5cIAHgOh3uLzl7bygskwBPKl3FlHNkapkx8+TTgbgKqo/68= X-Received: by 10.202.59.212 with SMTP id i203mr7459457oia.59.1506090011002; Fri, 22 Sep 2017 07:20:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 22 Sep 2017 07:20:10 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Loganaden Velvindron Date: Fri, 22 Sep 2017 18:20:10 +0400 Message-ID: To: Eric Rescorla Cc: Daniel Migault , "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Kathleen Moriarty , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 14:20:14 -0000 On Fri, Sep 22, 2017 at 5:51 PM, Eric Rescorla wrote: > Fantastic. I just hadn't heard from him yet and wanted to make sure we > agreed on who had the job > Hello Eric, It's my fault for not responding earlier. I admit that the IESG review is quite complex for someone who is going through it the first time. I was more comfortable with Mark responding as he has more experience than me, dealing with the IESG. From nobody Fri Sep 22 07:30: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 E5F69132F8F; Fri, 22 Sep 2017 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkZxwxr-8xMN; Fri, 22 Sep 2017 07:30:48 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 AF23A132D8A; Fri, 22 Sep 2017 07:30:48 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id p87so635111pfj.9; Fri, 22 Sep 2017 07:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5rgKZiVuPHcqS5OAfR+1o6WdFFh460vA0NeYT4Hg8W8=; b=co0WTU9u/LK1DdhJzsKRs780UGas/ufZ9cCHGU6MRZZgdAikNQ4UCWqDsQXyO6Tp7T U9OaaOyzLQCkiheH8oKV9Hv9XnQoqh/8ATEufZh7iAyPmkrJiJtAyJefaRsUOs2Xyjhs 6wBYuRyWQhAIHjMGHdJJMWzKU5dA1b3QjMtRy+KuhUXg79IVnCjmF6qLp7hW9ij/UZZv u1k7rPngYUCcznIZMQJxsdv6bnNOz2Jvqb5xC9pSp0s/Fki5nFHRN5bYI68kwa890SGu MSa/dX+CiztVhjgj7SQs/2WnK7aiMM1KBMaFoTN9YyqsAP0+MgdvI50uq5Mwk6BsSdo2 5lDQ== 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=5rgKZiVuPHcqS5OAfR+1o6WdFFh460vA0NeYT4Hg8W8=; b=CoJcYycb1N4cxWjSEcLPmlvL+0aey9f6aTyOF+cSXgbmNk4udzFXH2WRQlFrFE4uI3 D1lYwhr0igoApYLnniWYWp6iwFu4CuW7xsWUYHMyVk4y9iAX0PJ2yGeQl04o5mQv5i3M ruuS7K4Wb5/x7aOYTgsgwLzYyx6F4txBiuK413pQCbUVhr0B/a1aHiiVOfwT6/DXc4WD qsox8pAPjsny835m3boAsAw2kSO6KiMMd1XxN0epp5riIdNcLpDTHwKyvmSylK2NHge3 uenr+vTQpwVshzaosocaGMLApf7EWfgLyi3oyX1em86hHOtMVzsLrhZjGFa2u324bI3g vhSw== X-Gm-Message-State: AHPjjUiuNJfc/bV1cTEzigdNV35CWlaWqViDz3vVkn5sI2/w2AbXBlBD vK4JUV2tcZkcbWS8AOHwhJhc3BUZh2AqcbUSd+0= X-Google-Smtp-Source: AOwi7QCxvSCiw7I/Lx+vVqhwA9Y+9i9d7OwthpoPRinkFFFIwsBJb+xwz3osN2/vHzrkjLmgAyvT8sUaDloojxPeFfM= X-Received: by 10.84.211.144 with SMTP id c16mr9061697pli.233.1506090648249; Fri, 22 Sep 2017 07:30:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Fri, 22 Sep 2017 07:30:07 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Kathleen Moriarty Date: Fri, 22 Sep 2017 10:30:07 -0400 Message-ID: To: Loganaden Velvindron Cc: Eric Rescorla , Daniel Migault , "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 14:30:51 -0000 On Fri, Sep 22, 2017 at 10:20 AM, Loganaden Velvindron wrote: > On Fri, Sep 22, 2017 at 5:51 PM, Eric Rescorla wrote: >> Fantastic. I just hadn't heard from him yet and wanted to make sure we >> agreed on who had the job >> > > Hello Eric, > > It's my fault for not responding earlier. I admit that the IESG review > is quite complex for someone who is going through it the first time. I > was more comfortable with Mark responding as he has more experience > than me, dealing with the IESG. Thank you. I guess some of the nuances can be confusing, like a YES ballot with a comment. The last suggested update would be very helpful so anyone reading it would know that they shouldn't just go for the minimum as that could be phased out within a few years. -- Best regards, Kathleen From nobody Fri Sep 22 10:07: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 995B71342E0; Fri, 22 Sep 2017 10:07:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150610006853.16577.6958221904913177758@ietfa.amsl.com> Date: Fri, 22 Sep 2017 10:07:48 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 17:07:49 -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 WG of the IETF. Title : Increase SSH minimum recommended DH modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-06.txt Pages : 4 Date : 2017-09-22 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minimum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors, and possibly any organization with enough computing resources. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 22 10:14: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 4C617134557 for ; Fri, 22 Sep 2017 10:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 YyLsKi7zAiEp for ; Fri, 22 Sep 2017 10:14:10 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965B813454C for ; Fri, 22 Sep 2017 10:14:07 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q11so4522437ioe.10 for ; Fri, 22 Sep 2017 10:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oYw9p7huPaQCcvrX8D7EbHOyHcX0Px/KIcWXohzNUas=; b=g8GwBORPhVrbvauPMhxjMFib0qPNLZRAd38ZF5TMP5EBjAQBtHTjK3bNygdiF2onWH UmeYkIQQ4KfaMyodFyQZE5S30Ob/DZ6lPM5+deHbRQt+J+CIY50Wcy6XeOW3SPIBCggu O5kxDzPQrdV1idyOfu8yIWdNTXdCzv2GNM0aTF+c1UxmBzkDZQT0Ny4FUQZVrBKm816L pNkIDTKNePqTuXlk2b1OeLvJ1+kAFjuagzyKD45KoFs7jrEbzpVNwO6xYLaWl2V2O86b +QHs4KY52h28lM3bX7oJ9s265QeJ5HehNRP4RndU5TV9lYJFblcx7Y1P2raIVLmeHiP1 EE2w== 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=oYw9p7huPaQCcvrX8D7EbHOyHcX0Px/KIcWXohzNUas=; b=meay2a+5/OQkbVbPuuXy4AhyHZLsBR5nEPaxEmkt/5cRPaxm8AUOefUR9z57Y/jph2 MDf01vdLUPlRHbVZQStCb34CMKbMGtUqTKse7tzvw7EeDDAep19DYvyvb9OFLTWnxwe6 ga6QDlTXT5HgcWoFQola8/qIuAPvWyihqWCCDBS8GPJ1JqA2ZmNMYs+BRreb+i3rqRPc q2cJiK55aAvIZRIkPB05eGc6Ym2P4yroXDSTFHmnNQ8QNjPwUcxyL8/geqT4RhtG4/4U bFhKeqUsYDIFLTv3Abqucd2TmoLt1kn5qIAddu0uFfUu+VMx8nvPqfaxAi1GSh32kJ6L Q7YQ== X-Gm-Message-State: AHPjjUhbounLx6BZnV4bMl86o8f3IGPKBfQBTOoSttjQD/0KiCriHP5h 39GHz8IClRQgu5oQaSwx5KTJkGu2MHD3RUJe0b9Aaw== X-Google-Smtp-Source: AOwi7QCR0ST9U8CyREF1h3H0kNZQwMpo47fIUgU8tX+QcW+jR93VnqFfpC5yxR10fIPzyebclXLHvQTPLTP0Mdi5pAI= X-Received: by 10.202.104.206 with SMTP id o75mr7615345oik.31.1506100446909; Fri, 22 Sep 2017 10:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 22 Sep 2017 10:14:06 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Loganaden Velvindron Date: Fri, 22 Sep 2017 21:14:06 +0400 Message-ID: To: Kathleen Moriarty Cc: Eric Rescorla , Daniel Migault , "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 17:14:11 -0000 On Fri, Sep 22, 2017 at 6:30 PM, Kathleen Moriarty wrote: > On Fri, Sep 22, 2017 at 10:20 AM, Loganaden Velvindron wrote: >> On Fri, Sep 22, 2017 at 5:51 PM, Eric Rescorla wrote: >>> Fantastic. I just hadn't heard from him yet and wanted to make sure we >>> agreed on who had the job >>> >> >> Hello Eric, >> >> It's my fault for not responding earlier. I admit that the IESG review >> is quite complex for someone who is going through it the first time. I >> was more comfortable with Mark responding as he has more experience >> than me, dealing with the IESG. > > Thank you. I guess some of the nuances can be confusing, like a YES > ballot with a comment. The last suggested update would be very > helpful so anyone reading it would know that they shouldn't just go > for the minimum as that could be phased out within a few years. > > Yes, and it seems that it's hard to follow the point at which consensus is reached. I have attempted to address your concern, and most of the others in rev 06. Changelog: an->any; typo from warren; fix normative reference & ipr trust from mirja; include section about logging in security considerations from Benoit Claise and OPS DIR; include suggestions about 3072 bits as an option for implementation should the need arise in the coming years from K.Moriarty and S. Dawkins. From nobody Fri Sep 22 10:23: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 AC8BE13452A for ; Fri, 22 Sep 2017 10:23:11 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 bAxhLNErjcFH for ; Fri, 22 Sep 2017 10:23:10 -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 544B313455F for ; Fri, 22 Sep 2017 10:23:07 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id g32so4620193ioj.2 for ; Fri, 22 Sep 2017 10:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FDW1t5BEO+bNJwPf3kkPd+/HgpSLNM3dFc410cyJgq0=; b=dkMG4Sw413Lb4D82rf8Dc0FJ2iSP/55kGqYbauYnTwryXmNYLkLHPAqr0FuE8sgrV2 nEwijg9pUMzYG1AC4akCB/BrScvyPcPkWcn0MnCsky6QdYdbq5BNT6j40AWTpUhN3lQr gRi0TjG2YHyXoD0udEgq6iwE4s2Fj2sZt28jIwsLhEjSUqP6rZSD4b8xDqD9KD+X0o5p QwI/WyRkM+A7ZQwvvfk+1wcFgV8+jbizNVscF2089atNYtWeTTbehBhmGODb0FDKd3+g hKu5ncWd0+zeM6gjpNRrfCQzMH0kspXhFzyvbIl/BWTaekDsVqd/dNacd+ypUEUtNDIw U4vg== 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=FDW1t5BEO+bNJwPf3kkPd+/HgpSLNM3dFc410cyJgq0=; b=Gov/LRcBIT4RDPcC46RpgVzKpGs3NmHm2jrhY+Jd638/yD5IYTeCusM11zxPe1M1ST S1zyxMJAtjxRfzSTkrgkKOmjqVbfFzDovnVFw2epyMXcKlvGuC90bMmwG51opWrz3Fat apq6YTdldtqff7l4YlKLTBXuOHHPbM2eknxwV/MB2STp6sVWWvxUhvLzFhFGTpGQ3i1l q4TQVp2kVGfvWIiFQE1Q6krg5ayDuaqh/UFx0kBKFzmb+owqEVzpDpK9Jyu8pZxxQ+ZQ W8Rw8I+mtRbiSzkqA3prJOJwv5gNHkmyiEWs1EfwHK+639wdjkWA+AZcY5bS/jkHcsjx ZXBA== X-Gm-Message-State: AHPjjUj2YxexLm5jeHAVOjzsh3kAZZF/Fu9hk1hfprqewBwxfe/6EOBZ 2Cm6dczc2YTWyHrMISpyZHzU0pISDkKuVWqOsmGmJA== X-Google-Smtp-Source: AOwi7QCVnS5llm9sZpuDaROTXvL9bPIE8ddWf/kLlldTxA/pTeuQSaq6l4wXsC1Ej7u2eljKn/O3sBwuaY4wcfzPWko= X-Received: by 10.202.198.131 with SMTP id w125mr7277763oif.120.1506100986653; Fri, 22 Sep 2017 10:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.61.206 with HTTP; Fri, 22 Sep 2017 10:23:05 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Loganaden Velvindron Date: Fri, 22 Sep 2017 21:23:05 +0400 Message-ID: To: Kathleen Moriarty Cc: Eric Rescorla , Daniel Migault , "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 17:23:11 -0000 On Fri, Sep 22, 2017 at 6:30 PM, Kathleen Moriarty wrote: > On Fri, Sep 22, 2017 at 10:20 AM, Loganaden Velvindron wrote: >> On Fri, Sep 22, 2017 at 5:51 PM, Eric Rescorla wrote: >>> Fantastic. I just hadn't heard from him yet and wanted to make sure we >>> agreed on who had the job >>> >> >> Hello Eric, >> >> It's my fault for not responding earlier. I admit that the IESG review >> is quite complex for someone who is going through it the first time. I >> was more comfortable with Mark responding as he has more experience >> than me, dealing with the IESG. > > Thank you. I guess some of the nuances can be confusing, like a YES > ballot with a comment. The last suggested update would be very > helpful so anyone reading it would know that they shouldn't just go > for the minimum as that could be phased out within a few years. > > Interestingly, this message about 3072 bits DH Group was sent to the OpenSSH mailing list recently: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-September/036217.html From nobody Fri Sep 22 10:36: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 0C4A513455B; Fri, 22 Sep 2017 10:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrGj9MCsIjPR; Fri, 22 Sep 2017 10:36:22 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EC5134559; Fri, 22 Sep 2017 10:36:22 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id p5so942608pgn.7; Fri, 22 Sep 2017 10:36:22 -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=sH0+IVuskMMfZ4RFuipGccbLUFa7vGd4c7h8X2pw2ys=; b=Z4p5/E9/IdIGX+eeTTAPPoF1QVvFsLUbNeY6JfMIvWiuxpRI+qZBDKGBsvIMvalTH+ ru6dGC0f+Kt7+CQXmaPvQ4ltBw9QhYRmaBCJSKs9KyEeqAoLM/T2gdYRB5Q0CU/IEtgZ qSvkA4DgsqBD56NOzOnm3q+HPU1ECCperMZMvNYKbu1bGkNyekp/Mk/9t56NBoNef0zA B4psggreqYO6pcw5cnUHbWQKIRDbuuBEQ96DmivR/vIzmBcuObAd3rNs4ME2m2FoBL2y SNMrPZIJ+VxptKIyiDJ4kARzpuE4WenWTyVqC5UJ/DAYIVBxoT2RGrcBNS17JUxHr8SA 5E2g== 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=sH0+IVuskMMfZ4RFuipGccbLUFa7vGd4c7h8X2pw2ys=; b=JnNAVCPFLkbK5lNScqtC3YHFwg7R5qseCMpzt/THh+wrlt8+SwibnOqTMS8QFdgvdg o8SEhen/Yw1JB1/SoOkyNJKjHqy7FCFy2ig6K47neSTiAZWK5JVOQv0rpLp5dQV5GZPr Kcd9Ceq01nRlklRI+5J33jR/rMeHgUBSPQPflA3kOFRkm3PenJBzULZCzS/YvlqmQJtr TFDZ0FwoGSZ41JTDYji5OCQY65OMCwe/nrFcngMe6T1sc3lRxS6yz3gpqqGiIci5DrIz EWm2UeEKiKI7zrMCmZQ/IXe++AbqNcUeVc1OHp7CwIcDtaQVVsQqWWt22J82JXn5vA6E 2N5A== X-Gm-Message-State: AHPjjUjUArdu+vnYKIea6CtIlqzXcjLNZHt00wjMz7n5MxOImeMlScaW LsONKfbNsRHT87G85UmvYIqBsu0ewRtdsIedpzc= X-Google-Smtp-Source: AOwi7QCFKgGBXjDUP//qXEmI2jQ+z1O8kzruCXHKifdRPgvrJk9zU3ZuYeJonj6A2/DRl2tIt+kqgkSBAJJLC6zOUkA= X-Received: by 10.84.233.69 with SMTP id k5mr9975810plt.260.1506101781921; Fri, 22 Sep 2017 10:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Fri, 22 Sep 2017 10:35:41 -0700 (PDT) In-Reply-To: References: <21187.1505924879@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CEE6E6@eusaamb107.ericsson.se> From: Kathleen Moriarty Date: Fri, 22 Sep 2017 13:35:41 -0400 Message-ID: To: Loganaden Velvindron Cc: Eric Rescorla , Daniel Migault , "Mark D. Baushke" , curdle , "Salz, Rich" , draft-ietf-curdle-ssh-dh-group-exchange , curdle , Spencer Dawkins at IETF , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Sep 2017 17:36:24 -0000 On Fri, Sep 22, 2017 at 1:23 PM, Loganaden Velvindron wrote: > On Fri, Sep 22, 2017 at 6:30 PM, Kathleen Moriarty > wrote: >> On Fri, Sep 22, 2017 at 10:20 AM, Loganaden Velvindron wrote: >>> On Fri, Sep 22, 2017 at 5:51 PM, Eric Rescorla wrote: >>>> Fantastic. I just hadn't heard from him yet and wanted to make sure we >>>> agreed on who had the job >>>> >>> >>> Hello Eric, >>> >>> It's my fault for not responding earlier. I admit that the IESG review >>> is quite complex for someone who is going through it the first time. I >>> was more comfortable with Mark responding as he has more experience >>> than me, dealing with the IESG. >> >> Thank you. I guess some of the nuances can be confusing, like a YES >> ballot with a comment. The last suggested update would be very >> helpful so anyone reading it would know that they shouldn't just go >> for the minimum as that could be phased out within a few years. >> >> > > Interestingly, this message about 3072 bits DH Group was sent to the > OpenSSH mailing list recently: > https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-September/036217.html Yes, interesting indeed, thanks for sharing. -- Best regards, Kathleen From nobody Sat Sep 23 21:00:08 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 BDB7A13235C; Sat, 23 Sep 2017 20:59:59 -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.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150622559971.6619.552565024841696399@ietfa.amsl.com> Date: Sat, 23 Sep 2017 20:59:59 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-15.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 04:00:00 -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 WG of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-15.txt Pages : 13 Date : 2017-09-23 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 25 09:05:11 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E71344B4; Mon, 25 Sep 2017 09:05:09 -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.62.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635550977.27759.15197603682552994097.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:05:09 -0700 Archived-At: Subject: [Curdle] Protocol Action: 'Increase SSH minimum recommended DH modulus size to 2048 bits' to Proposed Standard (draft-ietf-curdle-ssh-dh-group-exchange-06.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:05:10 -0000 The IESG has approved the following document: - 'Increase SSH minimum recommended DH modulus size to 2048 bits' (draft-ietf-curdle-ssh-dh-group-exchange-06.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ Technical Summary 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 update of RFC 4419 is mentioned in the header, the abstract and the introduction. Working Group Summary No controversy were noted Document Quality At least one Open Source implementation has implemented this: OpenSSH: http://freshbsd.org/commit/openbsd/2a2c1e4e7e3fcc787fa334f50347ee1d282fac45 Personnel Daniel Migault is the document shepherd, Eric Rescorla is the AD. From nobody Mon Sep 25 09:08: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 77A391344C1; Mon, 25 Sep 2017 09:07:48 -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.62.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635566848.27455.9527789415683752269.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:07:48 -0700 Archived-At: Subject: [Curdle] Protocol Action: 'More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)' to Proposed Standard (draft-ietf-curdle-ssh-modp-dh-sha2-09.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:07:48 -0000 The IESG has approved the following document: - 'More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)' (draft-ietf-curdle-ssh-modp-dh-sha2-09.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document received few reviews on the mailing list. However, discussions occur on whether: - choosing IKE vs TLS primes - choosing fixed primes versus random. The consensus for this document was to restraint to the primes defined for IKE. Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The draft describes the following key exchange algorithms: * diffie-hellman-group14-sha256 * diffie-hellman-group15-sha512 * diffie-hellman-group16-sha512 * diffie-hellman-group17-sha512 * diffie-hellman-group18-sha512 These suites have been at least partially implemented. [00],[2] * OpenSSH has implemented and distributed at least diffie-hellman-group14-sha256 it already [0] * Dropbear has preliminary support for diffie-hellman-group14-sha256 by Matt Johnston [1] * RLogin supports dh-group{14,15,16}-sha256 since version 2.19.8 [3]. * Tera Term committed dh-group{14,15,16}-sha256 support committed to trunk, and it will be included in next release. [4] * Poderosa [5] committed to support dh-group{14,15,16}-sha256 support where a pull request has been sent [6]. [00] http://ssh-comparison.quendi.de/comparison/kex.html [0] https://jbeekman.nl/blog/2015/05/ssh-logjam/ [1] http://www.ietf.org/mail-archive/web/secsh/current/msg01119.html [2] http://www.ietf.org/mail-archive/web/secsh/current/msg01139.html [3] http://nanno.dip.jp/softlib/man/rlogin/ [4] https://en.osdn.jp/projects/ttssh2/scm/svn/commits/6263 [5] http://poderosa.sourceforge.net/ in [6] https://github.com/poderosaproject/poderosa/pull/17 From nobody Mon Sep 25 09:27:35 2017 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B27DD1344B4; Mon, 25 Sep 2017 09:27:34 -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.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-pkix@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635685472.27734.6722937141525016898.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:27:34 -0700 Archived-At: Subject: [Curdle] Last Call: (Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure) to Internet 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: Mon, 25 Sep 2017 16:27:35 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure' as Internet 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-10-09. 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 specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5480: Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard - IETF stream) From nobody Mon Sep 25 12: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 CA18B13457A for ; Mon, 25 Sep 2017 12:49:56 -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 q7AWOdolO6yr for ; Mon, 25 Sep 2017 12:49:55 -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 10A2B134576 for ; Mon, 25 Sep 2017 12:49:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 404483005AE for ; Mon, 25 Sep 2017 15:49:54 -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 cANe6IfS6Jw1 for ; Mon, 25 Sep 2017 15:49:52 -0400 (EDT) Received: from [172.20.1.237] (h60.74.129.40.static.ip.windstream.net [40.129.74.60]) by mail.smeinc.net (Postfix) with ESMTPSA id 86F1E300277; Mon, 25 Sep 2017 15:49:52 -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: <150635685472.27734.6722937141525016898.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 15:49:51 -0400 Cc: Eric Rescorla , curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <25CA1581-1F48-4AC7-BE9E-4E4B282E6422@vigilsec.com> References: <150635685472.27734.6722937141525016898.idtracker@ietfa.amsl.com> To: IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Last Call: (Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure) to Internet Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Sep 2017 19:49:57 -0000 I have reviewed the document, and I believe it is ready for publication. Russ > On Sep 25, 2017, at 12:27 PM, The IESG = wrote: >=20 >=20 > The IESG has received a request from the CURves, Deprecating and a = Little > more Encryption WG (curdle) to consider the following document: - = 'Algorithm > Identifiers for Ed25519, Ed448, X25519 and X448 for use in > the Internet X.509 Public Key Infrastructure' > as Internet Standard >=20 > 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-10-09. 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. >=20 > Abstract >=20 >=20 > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the curve25519 and > curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. = The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information:=20 > rfc5480: Elliptic Curve Cryptography Subject Public Key Information = (Proposed Standard - IETF stream) >=20 >=20 >=20 From nobody Wed Sep 27 11:56: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 48291134AA0 for ; Wed, 27 Sep 2017 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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] 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 wo7QZjHZTaI4 for ; Wed, 27 Sep 2017 11:56:55 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 756011320CF for ; Wed, 27 Sep 2017 11:56:54 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id h16so3905520wrf.6 for ; Wed, 27 Sep 2017 11:56:54 -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=/w6QMLIqvdDLDdkHOebgGt5CLYoxijxfnTv44QeN1JM=; b=lGzWkIvql6Pv/ISEsUM5JXBd978NRnDO7xh5Dn29x5wTu3tMLDKC6McADcfTVF/U12 gNblTVk8z379qNJM1/lHotW/k9Kqrk/zxI3n53GVGWaAvQurY4CuWckdc47qIUBpcfjK 46fc5ImiENNKoCyj1ZEhPUrZQGcSkjK4X5+kPimDpO2HRGoJNclAHEJbvZwEHmq9vP6s 1z61D3kND0hldDyYENVANF4s2i4PAn2YBMuYlSojhFV3KFOeAt8UWyVVNMaAv3s7kb5i OBsKQOjrh3NsqB4MdrDCiwFj5cF3Xz1cyPO03f+qyGe6aD9KXF1s7FU8h2tB1oq3akQM hh7Q== 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=/w6QMLIqvdDLDdkHOebgGt5CLYoxijxfnTv44QeN1JM=; b=P11i7+cnXIWM80E1cO2jNdGLqrv+OnjTdPk+S8tkZv5bE+jkDXsAH7B+BunLcTPhqq Bo1HGIdmP3NikDm+//f2QzLU6km/OI5vI7uUGyg6CgtR7laTGZACiPTDBC6xbyuIIzkY g0GjOvnepdZ9oumakGVdyybFrtPzjYBt+UCtI0DNiX0CA93T/9m/2dR/u1EvmDv5n4of c2gwsIHVmZFJxQf/lwVDlpkRZlRaTGyk1QHDCDOkYphVbP9duYZNjJF1pNHkDYHvWKwo DdEk1CTGwv/InG4ksiyO9ncZj0uxwSpXkksUYUaeMHQwTd7jyrCvOhaGjxpw/TJTZuCI +nkw== X-Gm-Message-State: AMCzsaUM4kDyR3ZHpSZ1MIHfLTJ1LxclBRZfCMeLNNRGB8sshoyULgjL LANNGk5cLT0n064uxFSImGK5olgla1+p7r/h+V7Omg== X-Google-Smtp-Source: AOwi7QCF02qfeGhSU7XMgredIt+sFk5zzdFuV165wG2xUqLQmYbwWspWrOuzKim2uOGX+SCu6KCXjiVQmovW1EJmwiY= X-Received: by 10.25.0.144 with SMTP id 138mr914724lfa.64.1506538612909; Wed, 27 Sep 2017 11:56:52 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.25 with HTTP; Wed, 27 Sep 2017 11:56:52 -0700 (PDT) In-Reply-To: <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> From: Daniel Migault Date: Wed, 27 Sep 2017 14:56:52 -0400 X-Google-Sender-Auth: 7WL7BBC-_boFHyFKu4vCNAkY_is Message-ID: To: Jim Schaad Cc: Sean Turner , curdle Content-Type: multipart/alternative; boundary="001a113c9e0cdceacb055a305aa2" Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 18:56:57 -0000 --001a113c9e0cdceacb055a305aa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please find the shepherd write up: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherdw= riteup/ Feel free to comment, by the end of the week. Yours, Daniel Small comments: a) [I-D.ietf-curdle-pkix ] should also be added as normative and [I-D.ietf-curdle-pkix -3] as informational. I think the normative comment is missing Maybe a note to the editor should be added. We need to avoid the RFC being in the informational reference ;-) b) the draft may be named ietf-curdle-oid-registry to reflect a WG document c) title of section 2.1 may be removed and all its content placed in sectio= n 2 d) If that is possible would it be possible to indicate the exact location where the table is expected to be added. Currently my understanding is that it is not possible, but once the table will be added you will be 1) more specific and 2) add a link as an informal reference. On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad wrote: > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Thursday, June 8, 2017 12:55 PM > *To:* Sean Turner > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Hi, > > Thank you for updating the draft Jim and Rick. While reviewing the draft > for the shepherd -write up I came with a few comments/questions. Please > find my comments below. > > Yours, > > Daniel > > > > COMMENT A) > > The type of the draft is currently "informational". According to RFC 2026 > I am more incline to consider that BCP would be more appropriated. Any > thoughts on that ? > > The draft does not discuss any technical content. The draft describes the > set of OIDs that have been donated. In some ways, it also assigns OIDs th= at > have not been assigned by any other RFCs ( but only version-03 of the pki= x > draft). It also describes the creation of an IANA registry table, as well > as update procedure for adding new entries which includes, parameters to > provide, the review process to follow and the way the arc can be extended= . > > In that sense according to RFC2026 the document is essentially documentin= g > IETF operations and so BCP seems the appropriated type. > > [JLS] I am not sure how you would presume that this could be a BCP? What > practices are we recommending that be followed? I think that this makes > far more sense as informational. There is nothing that says that an > informational draft be technical. Lots of informational drafts are about > procedures or about thought processes. I would keep this where it is. > > > > COMMENT B) > > It might my fault as I commented on the earlier version the references [ > I-D.ietf-curdle-pkix > ] > for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs > reserved for a specific Description while not being assigned. As we have > the intention to keep these OIDs, I think you opened a better path to hav= e > a RFC as a reference than having an old version of a draft. > > I interpret the the following text as explaining why we ended up with > id-EdDSA25516-ph and id-EdDSA448-ph. > > """ > > After those registrations were > > done, there were still some unused values that can be used for other > > security groups, there were still some unused values. > """ > > > Placing the current document as the Reference would clarify, in my > opinion, the status of these OIDs. It may be useful to add some text that > provides more explication with an reference to [I-D.ietf-curdle-pkix > ]-03. > As the RFC editor will probably replace [I-D.ietf-curdle-pkix > ] > with the RFC number, It might also be better to have a specific > informational reference. > > [JLS] There is a request in the XML that the RFC editor make sure that > this specific reference point to the version of the ID and not the RFC. > However, it gets messy if you have [draft] and [draft-3] I the same > document as well. Visually, it is currently a hard thing to do. > > COMMENT C) > > The draft says: > > """ > > IANA is asked to create one new registry table. > > 2.1 > . > "SMI Security for Cryptographic Algorithms" Registry > > > > Within the SMI-numbers registry, add an "SMI Security for > > Cryptographic Algorithms" table with the three columns: > > """ > > Maybe we should also specify that the SMI Security for Cryptographic > Algorithm registry is a sub-item of the "SMI Security Codes Registries". > > > I believe it would be useful to have an URL as an informational reference > for both the "SMI-numbers registry" as well as for "SMI Security Codes > Registries". > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml > https://www.iana.org/assignments/smi-numbers/smi- > numbers.xhtml#smi-numbers-26 > > Although I am not aware of a registration procedure for these tables and > the current, I believe it would be useful to specify explicitly all field= s > associated to the table. > > - Registration: Procedure Although it can be inferred from the curren= t > text. I believe it is helpful to the IANA to have the exact filed value > associated to all fields. > > - Description: The description is usually the arc ID, maybe in our > case we should add the range of provided OIDs. > > - Reference: It seems to me that the current document would be > appropriated. > > - Expert: The Registration Procedure mentions Expert review. I am not > sure experts should be listed in the in the RFC RFC5226 appointed by > IESG. > > > > [JLS] This is really a bit of a mess, because it does not really belong > under the SMI Security Codes section if one were being string. It is not > prefixed with the OID defined for that section. It is unfortunate that > Russ had all of the PKIX and S/MIME registries placed below that section. > However using the registry template associated with that would not really > be correct. I may talk to IANA during the process of final registration = to > see if we can create a new header and move all of the registries into tha= t > new header but I don=E2=80=99t want to do that as part of this document a= s it > probably would be messy to state. This type of decision is normally made > on the fly during the registration process and is not normally called out > explicitly. > > > > Experts are normally suggested by the authors, chairs or shepherds of the > document during the IESG review process at the request of the AD. > > > > We will end up with an entry that looks like https://www.iana.org/ > assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 which provides > a template of what is defined here. > > > > jim > > > > > > > > On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner wrote: > > I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s go= ing to do and > it=E2=80=99s pretty darn short and straight forward. Ship it! > > spt > > > > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > > > Hi, > > > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The > draft received significant comments during the WG adoption and is expecte= d > to be close to its final version. Please provide your feed backs by June = 16. > > > > Yours, > > Rich and Daniel > > > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a113c9e0cdceacb055a305aa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Feel free to comment, by the end of the week.

Yours,
Daniel

Smal= l comments:
a)
[I-D.ietf-curdle-pkix] should also be added as normative an=
d 
[I-D.ietf-curdle-pkix-3] as information=
al. I think the normative comment is missing
Maybe a note to the editor should be added. We need to avoid the RF=
C being in the informational reference ;-)
b) the draft may be named ietf-curdle-oid-registry to reflect a WG do=
cument

c) title of section 2.1 ma=
y be removed and all its content placed in section 2

d) If that is possible would it be possible to indicate=
 the exact location where the 
table is expected to be added. Currently =
my understanding is that it is not possible, 
but once the table will be=
 added you will be 1) more specific and 2) add a link as an
=C2=A0inform=
al reference.


On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad <ie= tf@augustcellars.com> wrote:

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

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

= =C2=A0

Hi,

=

Thank you for updatin= g the draft Jim and Rick. While reviewing the draft for the shepherd -write= up I came with a few comments/questions.=C2=A0 Please find my comments bel= ow.

Yours,

Daniel

<= p class=3D"MsoNormal">=C2=A0

COMMENT A)

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

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

In that sense according to RFC2026 the d= ocument is essentially documenting IETF operations and so BCP seems the app= ropriated type.

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

=C2= =A0

COMMENT B)=

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

I interpre= t the the following text as explaining why we ended up with id-EdDSA25516-p= h and id-EdDSA448-ph.

"""

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

=C2=A0=C2=A0 security groups, there were still some u=
nused values.
"""


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

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

<= /div>

COMMENT C)

"""

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

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

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

=

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

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

=C2=A0

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

=C2= =A0

E= xperts are normally suggested by the authors, chairs or shepherds of the do= cument during the IESG review process at the request of the AD. <= /u>

= =C2=A0

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

=C2=A0

jim

<= /font>

=C2=A0

=C2=A0

<= /div>

=C2=A0

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

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

spt


> On Jun 2, 2017, at 16:39, Daniel Migault <= daniel.mig= ault@ericsson.com> wrote:
>
> Hi,
>
> This e= mail starts a WGLC for draft-schaad-curdle-oid-registry[1]. The draft = received significant comments during the WG adoption and is expected to be = close to its final version. Please provide your feed backs by June 16.
&= gt;
> Yours,
> Rich and Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-<= wbr>registry/

> _______________________________________________
> Curd= le mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/cu= rdle

_______________________________________________
Cur= dle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle<= u>

<= /u>=C2=A0


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

--001a113c9e0cdceacb055a305aa2-- From nobody Wed Sep 27 12:01: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 810191320CF for ; Wed, 27 Sep 2017 12:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnmCFdoua_2N for ; Wed, 27 Sep 2017 12:01:32 -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 E48271342FF for ; Wed, 27 Sep 2017 12:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3F2B63005AE for ; Wed, 27 Sep 2017 15:01:31 -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 aVjNOHpEN9fp for ; Wed, 27 Sep 2017 15:01:25 -0400 (EDT) Received: from [172.20.1.237] (h60.74.129.40.static.ip.windstream.net [40.129.74.60]) by mail.smeinc.net (Postfix) with ESMTPSA id 8D4FC3002A3; Wed, 27 Sep 2017 15:01:25 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_48661FB4-CD3D-45EC-9E67-E11468BD2FD5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Sep 2017 15:01:24 -0400 In-Reply-To: Cc: Jim Schaad , curdle , Sean Turner To: Daniel Migault References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 19:01:34 -0000 --Apple-Mail=_48661FB4-CD3D-45EC-9E67-E11468BD2FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Daniel Migault is the document shepherd and Eric Rescorla is the = responsible Area.=20 s/Area/Area Director/ Some questions do not have answers: (8), (13), (15) Russ > On Sep 27, 2017, at 2:56 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > Please find the shepherd write up: >=20 > = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherd= writeup/ = >=20 > Feel free to comment, by the end of the week.=20 >=20 > Yours,=20 > Daniel >=20 > Small comments: > a) > [I-D.ietf-curdle-pkix = ] should also be added as normative and=20 > [I-D.ietf-curdle-pkix = -3] as informational. I think the normative comment is = missing > Maybe a note to the editor should be added. We need to avoid the RFC = being in the informational reference ;-) > b) the draft may be named ietf-curdle-oid-registry to reflect a WG = document >=20 > c) title of section 2.1 may be removed and all its content placed in = section 2 >=20 > d) If that is possible would it be possible to indicate the exact = location where the=20 > table is expected to be added. Currently my understanding is that it = is not possible,=20 > but once the table will be added you will be 1) more specific and 2) = add a link as an > informal reference.=20 >=20 >=20 > On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad > wrote: > =20 >=20 > =20 >=20 > From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Daniel Migault > Sent: Thursday, June 8, 2017 12:55 PM > To: Sean Turner > > Cc: curdle > > Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry >=20 > =20 >=20 > Hi, >=20 > Thank you for updating the draft Jim and Rick. While reviewing the = draft for the shepherd -write up I came with a few comments/questions. = Please find my comments below. >=20 > Yours, >=20 > Daniel >=20 > =20 >=20 > COMMENT A) >=20 > The type of the draft is currently "informational". According to RFC = 2026 I am more incline to consider that BCP would be more appropriated. = Any thoughts on that ? >=20 > The draft does not discuss any technical content. The draft describes = the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 = of the pkix draft). It also describes the creation of an IANA registry = table, as well as update procedure for adding new entries which = includes, parameters to provide, the review process to follow and the = way the arc can be extended.=20 >=20 > In that sense according to RFC2026 the document is essentially = documenting IETF operations and so BCP seems the appropriated type. >=20 > [JLS] I am not sure how you would presume that this could be a BCP? = What practices are we recommending that be followed? I think that this = makes far more sense as informational. There is nothing that says that = an informational draft be technical. Lots of informational drafts are = about procedures or about thought processes. I would keep this where it = is. >=20 > =20 >=20 > COMMENT B)=20 >=20 > It might my fault as I commented on the earlier version the references = [I-D.ietf-curdle-pkix = ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks = confusing to have OIDs reserved for a specific Description while not = being assigned. As we have the intention to keep these OIDs, I think you = opened a better path to have a RFC as a reference than having an old = version of a draft.=20 >=20 > I interpret the the following text as explaining why we ended up with = id-EdDSA25516-ph and id-EdDSA448-ph.=20 >=20 > """ >=20 > After those registrations were > done, there were still some unused values that can be used for = other > security groups, there were still some unused values. > """ >=20 > Placing the current document as the Reference would clarify, in my = opinion, the status of these OIDs. It may be useful to add some text = that provides more explication with an reference to = [I-D.ietf-curdle-pkix = ]-03. As the RFC editor will probably replace = [I-D.ietf-curdle-pkix = ] with the RFC number, It might also be better to have a = specific informational reference. =20 >=20 > [JLS] There is a request in the XML that the RFC editor make sure that = this specific reference point to the version of the ID and not the RFC. = However, it gets messy if you have [draft] and [draft-3] I the same = document as well. Visually, it is currently a hard thing to do. >=20 >=20 > COMMENT C) >=20 > The draft says: >=20 > """ >=20 > IANA is asked to create one new registry table. > <>2.1 = . "SMI Security for Cryptographic Algorithms" Registry >=20 > =20 > Within the SMI-numbers registry, add an "SMI Security for > Cryptographic Algorithms" table with the three columns: > """ >=20 > Maybe we should also specify that the SMI Security for Cryptographic = Algorithm registry is a sub-item of the "SMI Security Codes Registries".=20= >=20 >=20 > I believe it would be useful to have an URL as an informational = reference for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".=20 >=20 > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml = > = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -26 = > Although I am not aware of a registration procedure for these tables = and the current, I believe it would be useful to specify explicitly all = fields associated to the table. >=20 > - Registration: Procedure Although it can be inferred from the = current text. I believe it is helpful to the IANA to have the exact = filed value associated to all fields. >=20 > - Description: The description is usually the arc ID, maybe in our = case we should add the range of provided OIDs. >=20 > - Reference: It seems to me that the current document would be = appropriated. >=20 > - Expert: The Registration Procedure mentions Expert review. I am = not sure experts should be listed in the in the RFC RFC5226 appointed = by IESG.=20 >=20 > =20 >=20 > [JLS] This is really a bit of a mess, because it does not really = belong under the SMI Security Codes section if one were being string. = It is not prefixed with the OID defined for that section. It is = unfortunate that Russ had all of the PKIX and S/MIME registries placed = below that section. However using the registry template associated with = that would not really be correct. I may talk to IANA during the process = of final registration to see if we can create a new header and move all = of the registries into that new header but I don=E2=80=99t want to do = that as part of this document as it probably would be messy to state. = This type of decision is normally made on the fly during the = registration process and is not normally called out explicitly. >=20 > =20 >=20 > Experts are normally suggested by the authors, chairs or shepherds of = the document during the IESG review process at the request of the AD. >=20 > =20 >=20 > We will end up with an entry that looks like = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-sm= ime-3 = which provides a template of what is defined here. >=20 > =20 >=20 > jim >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner > wrote: >=20 > I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! >=20 > spt >=20 >=20 > > On Jun 2, 2017, at 16:39, Daniel Migault = > = wrote: > > > > Hi, > > > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. = The draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16. > > > > Yours, > > Rich and Daniel > > > > [1] = https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ = > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle = >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle = > =20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle = >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_48661FB4-CD3D-45EC-9E67-E11468BD2FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
Daniel Migault is the document shepherd =
and Eric Rescorla is the responsible Area.
s/Area/Area Director/

Some questions do not have answers: = (8), (13), (15)

Russ


On Sep 27, 2017, at 2:56 PM, Daniel Migault = <daniel.migault@ericsson.com> wrote:

Hi,

Please find the shepherd write = up:

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

Feel free to comment, by the end of the week.

Yours,
Daniel

Small comments:
a)
[I-D.ietf-curdle-pkix] should also =
be added as normative and 
[I-D.ietf-curdle-pkix-3] as =
informational. I think the normative comment is missing
Maybe a note to the editor =
should be added. We need to avoid the RFC being in the informational =
reference ;-)
b) the =
draft may be named ietf-curdle-oid-registry to reflect a WG document

c) title of =
section 2.1 may be removed and all its content placed in section 2

d) If that =
is possible would it be possible to indicate the exact location where =
the 
table is expected to be added. Currently my =
understanding is that it is not possible, 
but once the =
table will be added you will be 1) more specific and 2) add a link as =
an
 informal reference.


On Thu, Jun 8, 2017 at 5:36 PM, = Jim Schaad <ietf@augustcellars.com> wrote:

 

 

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

 

Hi,

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

Yours,

Daniel

 

COMMENT A)

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

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

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

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

 

COMMENT B)

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

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

"""

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


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

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

COMMENT C)

The = draft says:

"""

IANA is asked to create one new =
registry table.

2.1.  "SMI Security for Cryptographic Algorithms" = Registry

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

"""

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


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

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26

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

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

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

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

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

 

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

 

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

 

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

 

jim

 

  =

 

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

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

spt


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

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

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

 


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


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

= --Apple-Mail=_48661FB4-CD3D-45EC-9E67-E11468BD2FD5-- From nobody Wed Sep 27 12:08: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 5F7DF134ED4 for ; Wed, 27 Sep 2017 12:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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] 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 fThzTP5k4x73 for ; Wed, 27 Sep 2017 12:08:11 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 C5178134BDA for ; Wed, 27 Sep 2017 12:08:10 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id m18so18179460wrm.2 for ; Wed, 27 Sep 2017 12:08:10 -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=SApsk8yXjsaS1is9l2SHQZx4U+5BR8P+3EMKtlPbqbo=; b=pA0ii93N3pbujc+yL7ObqrM7a/NTO/szuwJufw91Gpea0x9tZPla1JkA0IFT85xTWw B+fKQJmbbN+fquuYV9trcF4rsBuxVdnV8sNao2XZK7tzOuahFqovcg9uJDRDiu8EgPKL B3b8KaGvLO06wEeGCPpv5EN9sAdsWcYjkU+useMKOIQ6GCpot00gNkFXm7ZYeBLn78C3 NqTOkhx+hrjlhmdPiT9Foxn2P+/R1+nTheRB5pAD1RYdXeguvDTg/Wef0MMhK8x6U18D uPbW4KlPMjz7ngs5pWIv5Tjxt+eVfRHYBQTSQ2LLrKBMkqMDvA36MgDFh96B+g2u5czy bNtg== 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=SApsk8yXjsaS1is9l2SHQZx4U+5BR8P+3EMKtlPbqbo=; b=NVNB1QGQaDWRlMsbhfWD+M+TjvZqEomdnqi7L1LsdA2VFKvEIABI4dUBVEw8ZFenSF Vog4iCeoGHg+vY8c+jlcgKeAgE83UlDOtPvDUsvJzeLE5sH7A0Il/GND6Jmjf3F82MR5 hUdgevkDhkAZ8+8QpwGfxt/hAvG7zZ8VgWWuPDi/x+h3otuq3CdSrzXnsKCDN0RqjaTO YVmCm6up09KCxHF4wmIClsWxT3PEjBVMRONt/PlC4y6S5DYWDiLasz6UKNG1aXF9qISK OXcij52LVQ2Pl5d0yQGcOJRpOWVIkmNQLLkxKAKw0wb+CCAg3ArHWUJwvNTWO14ac6Am 1Xww== X-Gm-Message-State: AMCzsaXGIMKvYBJwCR64KayQH8AUbCwvuUHy6OVUJTayRljmLlyZZuR+ dAyK5/LbJaJPOYLxx7uEcsi6qEy5CMBRcJrT1pI= X-Google-Smtp-Source: AOwi7QDqCPAa55Amii7d+9TMAaytmQcf/lE7h55JAF06/FgyMi5MzOtnrN+n+79R0SAMx2Bj/GKgraoPBZ3a2g9BDVQ= X-Received: by 10.25.204.198 with SMTP id c189mr929040lfg.49.1506539289303; Wed, 27 Sep 2017 12:08:09 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.25 with HTTP; Wed, 27 Sep 2017 12:08:08 -0700 (PDT) In-Reply-To: References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> From: Daniel Migault Date: Wed, 27 Sep 2017 15:08:08 -0400 X-Google-Sender-Auth: ConDiuabYE1_BlbeB_2S6FkF2ww Message-ID: To: Russ Housley Cc: Jim Schaad , curdle , Sean Turner Content-Type: multipart/alternative; boundary="94eb2c1a07fe2dde8b055a3083ac" Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 19:08:14 -0000 --94eb2c1a07fe2dde8b055a3083ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. It is better to be explicit and complete.These have been addressed. Yours, Daniel On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley wrote: > Daniel Migault is the document shepherd and Eric Rescorla is the responsi= ble Area. > > s/Area/Area Director/ > > Some questions do not have answers: (8), (13), (15) > > Russ > > > On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: > > Hi, > > Please find the shepherd write up: > > https://datatracker.ietf.org/doc/draft-schaad-curdle-oid- > registry/shepherdwriteup/ > > Feel free to comment, by the end of the week. > > Yours, > Daniel > > Small comments: > a) > > [I-D.ietf-curdle-pkix ] should also be added as normative = and > [I-D.ietf-curdle-pkix -3] as informational. I think the no= rmative comment is missing > > Maybe a note to the editor should be added. We need to avoid the RFC bein= g in the informational reference ;-) > > b) the draft may be named ietf-curdle-oid-registry to reflect a WG docume= nt > > c) title of section 2.1 may be removed and all its content placed in sect= ion 2 > > d) If that is possible would it be possible to indicate the exact locatio= n where the > table is expected to be added. Currently my understanding is that it is n= ot possible, > but once the table will be added you will be 1) more specific and 2) add = a link as an > informal reference. > > > On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad wrote= : > >> >> >> >> >> *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel >> Migault >> *Sent:* Thursday, June 8, 2017 12:55 PM >> *To:* Sean Turner >> *Cc:* curdle >> *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry >> >> >> >> Hi, >> >> Thank you for updating the draft Jim and Rick. While reviewing the draft >> for the shepherd -write up I came with a few comments/questions. Please >> find my comments below. >> >> Yours, >> >> Daniel >> >> >> >> COMMENT A) >> >> The type of the draft is currently "informational". According to RFC 202= 6 >> I am more incline to consider that BCP would be more appropriated. Any >> thoughts on that ? >> >> The draft does not discuss any technical content. The draft describes th= e >> set of OIDs that have been donated. In some ways, it also assigns OIDs t= hat >> have not been assigned by any other RFCs ( but only version-03 of the pk= ix >> draft). It also describes the creation of an IANA registry table, as wel= l >> as update procedure for adding new entries which includes, parameters to >> provide, the review process to follow and the way the arc can be extende= d. >> >> In that sense according to RFC2026 the document is essentially >> documenting IETF operations and so BCP seems the appropriated type. >> >> [JLS] I am not sure how you would presume that this could be a BCP? Wha= t >> practices are we recommending that be followed? I think that this makes >> far more sense as informational. There is nothing that says that an >> informational draft be technical. Lots of informational drafts are abou= t >> procedures or about thought processes. I would keep this where it is. >> >> >> >> COMMENT B) >> >> It might my fault as I commented on the earlier version the references [ >> I-D.ietf-curdle-pkix >> ] >> for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs >> reserved for a specific Description while not being assigned. As we have >> the intention to keep these OIDs, I think you opened a better path to ha= ve >> a RFC as a reference than having an old version of a draft. >> >> I interpret the the following text as explaining why we ended up with >> id-EdDSA25516-ph and id-EdDSA448-ph. >> >> """ >> >> After those registrations were >> >> done, there were still some unused values that can be used for other >> >> security groups, there were still some unused values. >> """ >> >> >> Placing the current document as the Reference would clarify, in my >> opinion, the status of these OIDs. It may be useful to add some text tha= t >> provides more explication with an reference to [I-D.ietf-curdle-pkix >> ]-03. >> As the RFC editor will probably replace [I-D.ietf-curdle-pkix >> ] >> with the RFC number, It might also be better to have a specific >> informational reference. >> >> [JLS] There is a request in the XML that the RFC editor make sure that >> this specific reference point to the version of the ID and not the RFC. >> However, it gets messy if you have [draft] and [draft-3] I the same >> document as well. Visually, it is currently a hard thing to do. >> >> COMMENT C) >> >> The draft says: >> >> """ >> >> IANA is asked to create one new registry table. >> >> 2.1 >> . >> "SMI Security for Cryptographic Algorithms" Registry >> >> >> >> Within the SMI-numbers registry, add an "SMI Security for >> >> Cryptographic Algorithms" table with the three columns: >> >> """ >> >> Maybe we should also specify that the SMI Security for Cryptographic >> Algorithm registry is a sub-item of the "SMI Security Codes Registries". >> >> >> I believe it would be useful to have an URL as an informational referenc= e >> for both the "SMI-numbers registry" as well as for "SMI Security Codes >> Registries". >> >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml >> https://www.iana.org/assignments/smi-numbers/smi-numbers. >> xhtml#smi-numbers-26 >> >> Although I am not aware of a registration procedure for these tables and >> the current, I believe it would be useful to specify explicitly all fiel= ds >> associated to the table. >> >> - Registration: Procedure Although it can be inferred from the >> current text. I believe it is helpful to the IANA to have the exact file= d >> value associated to all fields. >> >> - Description: The description is usually the arc ID, maybe in our >> case we should add the range of provided OIDs. >> >> - Reference: It seems to me that the current document would be >> appropriated. >> >> - Expert: The Registration Procedure mentions Expert review. I am no= t >> sure experts should be listed in the in the RFC RFC5226 appointed by >> IESG. >> >> >> >> [JLS] This is really a bit of a mess, because it does not really belong >> under the SMI Security Codes section if one were being string. It is no= t >> prefixed with the OID defined for that section. It is unfortunate that >> Russ had all of the PKIX and S/MIME registries placed below that section= . >> However using the registry template associated with that would not reall= y >> be correct. I may talk to IANA during the process of final registration= to >> see if we can create a new header and move all of the registries into th= at >> new header but I don=E2=80=99t want to do that as part of this document = as it >> probably would be messy to state. This type of decision is normally mad= e >> on the fly during the registration process and is not normally called ou= t >> explicitly. >> >> >> >> Experts are normally suggested by the authors, chairs or shepherds of th= e >> document during the IESG review process at the request of the AD. >> >> >> >> We will end up with an entry that looks like >> https://www.iana.org/assignments/smi-numbers/smi-numbers. >> xhtml#security-smime-3 which provides a template of what is defined here= . >> >> >> >> jim >> >> >> >> >> >> >> >> On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner wrote: >> >> I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s g= oing to do and >> it=E2=80=99s pretty darn short and straight forward. Ship it! >> >> spt >> >> >> > On Jun 2, 2017, at 16:39, Daniel Migault >> wrote: >> > >> > Hi, >> > >> > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The >> draft received significant comments during the WG adoption and is expect= ed >> to be close to its final version. Please provide your feed backs by June= 16. >> > >> > Yours, >> > Rich and Daniel >> > >> > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ >> >> > _______________________________________________ >> > Curdle mailing list >> > Curdle@ietf.org >> > https://www.ietf.org/mailman/listinfo/curdle >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c1a07fe2dde8b055a3083ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. It is better to be explicit and complete= .These have been addressed.
Yours,
Daniel
<= br>

On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley <housley@vigilsec.com= > wrote:
Daniel Migaul=
t is the document shepherd and Eric Rescorla is the responsible Area. 
s/Area/Area Director/

Some questions do not =
have answers: (8), (13), (15)

Russ
<=
div>

On Sep 27,=
 2017, at 2:56 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi, 

Please find the shepherd write u=
p:


Feel free to comment, by the end of t=
he week. 

Yours, 
Daniel

Small comments:
a)
[I=
-D.ietf-curdle-pkix] should also be added as normative and 
[I-D.ietf-curdle-pkix-3] as informa=
tional. I think the normative comment is missing
Maybe a note to the editor should be adde=
d. We need to avoid the RFC being in the informational reference ;-)
b) the draft may be n=
amed ietf-curdle-oid-registry to reflect a WG document

c) title of section 2.1 may be =
removed and all its content placed in section 2

d) If that is possible would it be pos=
sible to indicate the exact location where the 
table is expected to be =
added. Currently my understanding is that it is not possible, 
but once =
the table will be added you will be 1) more specific and 2) add a link as a=
n
=C2=A0informal reference. 


On Thu, Jun 8, 2017 at 5:36 PM, Jim=
 Schaad <ietf@augustcellars.com> wrote:
=C2=A0
=C2=A0=

From: Curdle [mailto:curdle-bounces@ietf.or=
g] On Behalf Of Daniel Migault
Sent: Thursday, June 8,=
 2017 12:55 PM
To: Sean Turner <sean@sn3rd.com>
Cc: curdle <curdle@ietf.org>
=
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry<=
/u>
=C2=A0
Hi, 
Thank you for updating the draft Jim and Rick. While reviewing the =
draft for the shepherd -write up I came with a few comments/questions.=C2=
=A0 Please find my comments below.
Yours, 
Danie=
l
=C2=A0
COMMENT =
A) 
The type of the draft is currently "informational". Accordi=
ng to RFC 2026 I am more incline to consider that BCP would be more appropr=
iated. Any thoughts on that ?
The draft does not discus=
s any technical content. The draft describes the set of OIDs that have been=
 donated. In some ways, it also assigns OIDs that have not been assigned by=
 any other RFCs ( but only version-03 of the pkix draft). It also describes=
 the creation of an IANA registry table, as well as update procedure for ad=
ding new entries which includes, parameters to provide, the review process =
to follow and the way the arc can be extended. 

In that sense accord=
ing to RFC2026 the document is essentially documenting IETF operations and =
so BCP seems the appropriated type.
[JLS] =
I am not sure how you would presume that this could be a BCP?=C2=A0 What pr=
actices are we recommending that be followed?=C2=A0 I think that this makes=
 far more sense as informational.=C2=A0 There is nothing that says that an =
informational draft be technical.=C2=A0 Lots of informational drafts are ab=
out procedures or about thought processes.=C2=A0 I would keep this where it=
 is.
=C2=A0
COM=
MENT B) 

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

I i=
nterpret the the following text as explaining why we ended up with id-EdDSA=
25516-ph and id-EdDSA448-ph. 

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


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

<= span style=3D"color:#0070c0">[JLS] There is a request in the XML that the R= FC editor make sure that this specific reference point to the version of th= e ID and not the RFC. However, it gets messy if you have [draft] and [draft= -3] I the same document as well.=C2=A0 Visually, it is currently a hard thi= ng to do.

=

= COMMENT C)

The draft say= s:

"""

IANA is asked to create =
one new registry table.

2.1.=C2=A0 "SMI Security for Cryptographic Algorithms" Regis= try

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

"""

Maybe we should als= o specify that the SMI Security for Cryptographic Algorithm registry is a s= ub-item of the "SMI Security Codes Registries".


I bel= ieve it would be useful to have an URL as an informational reference for bo= th the "SMI-numbers registry" as well as for "SMI Security C= odes Registries".

https://www.iana.org/assig= nments/smi-numbers/smi-numbers.xhtml
https://www.iana.org/assignments/smi-numbers/smi-numbers.<= wbr>xhtml#smi-numbers-26

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

=C2=A0=C2=A0=C2=A0 - Registration: Procedure Although it can be inf= erred from the current text. I believe it is helpful to the IANA to have th= e exact filed value associated to all fields.

=C2=A0=C2=A0=C2=A0 - Description: The descri= ption is usually the arc ID, maybe in our case we should add the range of p= rovided OIDs.

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

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

=C2=A0

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

<= p class=3D"MsoNormal">=C2=A0

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

=C2=A0<= /span>

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

=C2=A0

jim

=C2=A0

=C2=A0

=C2=A0

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

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

spt


> On Jun 2, 2017, at 16:39= , Daniel Migault <daniel.migault@ericsson.com> wrote:
>
> Hi,<= br>>
> This email starts a WGLC for draft-schaad-curdle-oid-regist= ry[1]. The draft received significant comments during the WG adoption = and is expected to be close to its final version. Please provide your feed = backs by June 16.
>
> Yours,
> Rich and Daniel
>> [1] https://datatracker.ietf.org/doc/draft= -schaad-curdle-oid-registry/

> ________________________________________= _______
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mail= man/listinfo/curdle

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

=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


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

--94eb2c1a07fe2dde8b055a3083ac-- From nobody Wed Sep 27 18:26: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 96B90135224 for ; Wed, 27 Sep 2017 18:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rp8sgNsOe4zd for ; Wed, 27 Sep 2017 18:26: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 D4338135221 for ; Wed, 27 Sep 2017 18:26:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0261_01D337BE.046BE490" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506561916; h=from:subject:to:date:message-id; bh=Ik1n9h+71B2t2wKR4/ooTNOHVBVYsuw4egC2Qx9YvIM=; b=eVmczHoZoyscM18gBnQyw6MwYnqX+ivaEK2dHhfEiX660muLNKexo+6+QHBxr2L32hPq/tZHZNa C9SGuBNVcWdLgA4taZEiuLTyUX+nqbxsv2JZWGxRYCrfWgxn5yRbN8dzYGlVCFY/8L9rn1u3HvsTR WdNJiHICwzg0CeNvbGhABIuGoVEV9QTU804FDe/1jaIRD7AgHUDtWqwhDjaJMIVnABXYl4LteOKRh z7P6kVWqEreBsvUkEVUPd6iPfS4y/35mQ7dHkne1Bf4DOC4hK+P1JdPHdQ1s8X+qYyL1hOKLntzuA nCOgqJPzlh5d9qB5Z+QvyGNqmbKzmnlJQ3xA== 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, 27 Sep 2017 18:25:15 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 27 Sep 2017 18:24:52 -0700 From: Jim Schaad To: 'Daniel Migault' CC: 'curdle' References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> In-Reply-To: Date: Wed, 27 Sep 2017 18:25:35 -0700 Message-ID: <026001d337f8$b0c4f030$124ed090$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb1xZwqGaWy4iJzjCFcw91l4MwcAKUrU/kAn9JjwACxKIGkAHJEGYKAsAQmu4DfUDCtqE5SNuQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:26:15 -0000 ------=_NextPart_000_0261_01D337BE.046BE490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1. I would not use the phrase =E2=80=9CIn some ways=E2=80=9D. = =E2=80=9CIt uses the assignments made by the document = draft-ietf-curdle-pkix to prepopulate the table, including a pair of = assignments made during discussions that did not make the final = draft.=E2=80=9D Delete sentence 2, put this in as a new sentence 3. 2. As noted before, the instructions to deal with the reference to the = -03 draft are in the XML as a request to the RFC editor. 3. This registry does require Expert review per section 4.6 of RFC 8126. =20 Jim =20 =20 From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault Sent: Wednesday, September 27, 2017 12:08 PM To: Russ Housley Cc: Jim Schaad ; curdle ; Sean = Turner Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Thanks. It is better to be explicit and complete.These have been = addressed. Yours,=20 Daniel =20 =20 On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley > wrote: Daniel Migault is the document shepherd and Eric Rescorla is the = responsible Area.=20 s/Area/Area Director/ =20 Some questions do not have answers: (8), (13), (15) =20 Russ =20 =20 On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: =20 Hi,=20 Please find the shepherd write up: =20 https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepher= dwriteup/ =20 Feel free to comment, by the end of the week.=20 =20 Yours,=20 Daniel =20 Small comments: a) [I-D.ietf-curdle-pkix = ] should also be added as normative and=20 [I-D.ietf-curdle-pkix = -3] as informational. I think the normative comment is = missing Maybe a note to the editor should be added. We need to avoid the RFC = being in the informational reference ;-) b) the draft may be named ietf-curdle-oid-registry to reflect a WG = document c) title of section 2.1 may be removed and all its content placed in = section 2 d) If that is possible would it be possible to indicate the exact = location where the=20 table is expected to be added. Currently my understanding is that it is = not possible,=20 but once the table will be added you will be 1) more specific and 2) add = a link as an informal reference.=20 =20 On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad > wrote: =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Daniel Migault Sent: Thursday, June 8, 2017 12:55 PM To: Sean Turner > Cc: curdle > Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Hi,=20 Thank you for updating the draft Jim and Rick. While reviewing the draft = for the shepherd -write up I came with a few comments/questions. Please = find my comments below. Yours,=20 Daniel =20 COMMENT A)=20 The type of the draft is currently "informational". According to RFC = 2026 I am more incline to consider that BCP would be more appropriated. = Any thoughts on that ? The draft does not discuss any technical content. The draft describes = the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 = of the pkix draft). It also describes the creation of an IANA registry = table, as well as update procedure for adding new entries which = includes, parameters to provide, the review process to follow and the = way the arc can be extended.=20 In that sense according to RFC2026 the document is essentially = documenting IETF operations and so BCP seems the appropriated type. [JLS] I am not sure how you would presume that this could be a BCP? = What practices are we recommending that be followed? I think that this = makes far more sense as informational. There is nothing that says that = an informational draft be technical. Lots of informational drafts are = about procedures or about thought processes. I would keep this where it = is. =20 COMMENT B)=20 It might my fault as I commented on the earlier version the references = [I-D.ietf-curdle-pkix = ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks = confusing to have OIDs reserved for a specific Description while not = being assigned. As we have the intention to keep these OIDs, I think you = opened a better path to have a RFC as a reference than having an old = version of a draft.=20 I interpret the the following text as explaining why we ended up with = id-EdDSA25516-ph and id-EdDSA448-ph.=20 """ After those registrations were done, there were still some unused values that can be used for other security groups, there were still some unused values. """ Placing the current document as the Reference would clarify, in my = opinion, the status of these OIDs. It may be useful to add some text = that provides more explication with an reference to = [I-D.ietf-curdle-pkix = ]-03. As the RFC editor will probably replace = [I-D.ietf-curdle-pkix = ] with the RFC number, It might also be better to have = a specific informational reference. =20 [JLS] There is a request in the XML that the RFC editor make sure that = this specific reference point to the version of the ID and not the RFC. = However, it gets messy if you have [draft] and [draft-3] I the same = document as well. Visually, it is currently a hard thing to do. COMMENT C) The draft says: """ IANA is asked to create one new registry table. = 2.1. "SMI Security for Cryptographic Algorithms" Registry =20 Within the SMI-numbers registry, add an "SMI Security for Cryptographic Algorithms" table with the three columns: """ Maybe we should also specify that the SMI Security for Cryptographic = Algorithm registry is a sub-item of the "SMI Security Codes Registries". = I believe it would be useful to have an URL as an informational = reference for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".=20 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-26 Although I am not aware of a registration procedure for these tables and = the current, I believe it would be useful to specify explicitly all = fields associated to the table.=20 - Registration: Procedure Although it can be inferred from the = current text. I believe it is helpful to the IANA to have the exact = filed value associated to all fields.=20 - Description: The description is usually the arc ID, maybe in our = case we should add the range of provided OIDs. - Reference: It seems to me that the current document would be = appropriated. - Expert: The Registration Procedure mentions Expert review. I am = not sure experts should be listed in the in the RFC RFC5226 appointed = by IESG. =20 =20 [JLS] This is really a bit of a mess, because it does not really belong = under the SMI Security Codes section if one were being string. It is = not prefixed with the OID defined for that section. It is unfortunate = that Russ had all of the PKIX and S/MIME registries placed below that = section. However using the registry template associated with that would = not really be correct. I may talk to IANA during the process of final = registration to see if we can create a new header and move all of the = registries into that new header but I don=E2=80=99t want to do that as = part of this document as it probably would be messy to state. This type = of decision is normally made on the fly during the registration process = and is not normally called out explicitly. =20 Experts are normally suggested by the authors, chairs or shepherds of = the document during the IESG review process at the request of the AD.=20 =20 We will end up with an entry that looks like = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-s= mime-3 which provides a template of what is defined here. =20 jim =20 =20 =20 On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner > wrote: I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! spt > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > Hi, > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16. > > Yours, > Rich and Daniel > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > _______________________________________________ > Curdle mailing list > Curdle@ietf.org =20 > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_0261_01D337BE.046BE490 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
  1. I would not use the = phrase =E2=80=9CIn some ways=E2=80=9D.=C2=A0 =E2=80=9CIt uses the = assignments made by the document draft-ietf-curdle-pkix to prepopulate = the table, including a pair of assignments made during discussions that = did not make the final draft.=E2=80=9D=C2=A0=C2=A0=C2=A0 Delete sentence = 2, put this in as a new sentence 3.
  2. As noted before, the instructions to deal with the reference to = the -03 draft are in the XML as a request to the RFC = editor.
  3. This registry does = require Expert review per section 4.6 of RFC = 8126.

 

Jim

 

 

From: = mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault
Sent: Wednesday, September 27, 2017 12:08 = PM
To: Russ Housley <housley@vigilsec.com>
Cc: = Jim Schaad <ietf@augustcellars.com>; curdle = <curdle@ietf.org>; Sean Turner = <sean@sn3rd.com>
Subject: Re: [Curdle] WGLC = draft-schaad-curdle-oid-registry

 

Thanks. It is better to be explicit and complete.These = have been addressed.

Yours, =

Daniel

 

 

On Wed, = Sep 27, 2017 at 3:01 PM, Russ Housley <housley@vigilsec.com> = wrote:

Daniel Migault is =
the document shepherd and Eric Rescorla is the responsible Area. =

s/Area/Area = Director/

 

Some questions do not have answers: (8), (13), = (15)

 

Russ

 

 

On Sep 27, 2017, at 2:56 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:

 

Hi, =

Please find the shepherd write = up:

 

 

Feel free to comment, by the end of the week. =

 

Yours,

Daniel

 

Small = comments:

a)

[I-D.ietf-curdle-pkix] =
should also be added as normative and 
[I-D.ietf-curdle-pkix-3] =
as informational. I think the normative comment is =
missing
Maybe a note to the editor should be added. =
We need to avoid the RFC being in the informational reference =
;-)
b) the draft may =
be named ietf-curdle-oid-registry to reflect a WG =
document
c) title of =
section 2.1 may be removed and all its content placed in section =
2
d) If that is =
possible would it be possible to indicate the exact location where the =

table is expected to be added. Currently my understanding is that it =
is not possible, 
but once the table will be added you will be 1) =
more specific and 2) add a link as an
 informal reference. =

 

On Thu, = Jun 8, 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 <= /o:p>

 <= /o:p>

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

 <= /o:p>

Hi, =

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

Yours, =

Daniel<= /o:p>

 <= /o:p>

COMMENT A) =

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

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

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

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

 <= /p>

COMMENT B) =

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

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

"""

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


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

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

COMMENT = C)

The draft = says:

"""

IANA is asked to =
create one new registry table.

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

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

""= "

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


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

https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml
https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml#smi-numbers-26

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

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

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

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

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

 <= /o:p>

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

 

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

 

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

 

jim

  =

  =

 <= /o:p>

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

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

spt


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

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

 <= /o:p>


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

 

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

 


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

 

------=_NextPart_000_0261_01D337BE.046BE490-- From nobody Thu Sep 28 07: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 2B28C1330B1 for ; Thu, 28 Sep 2017 07:06:46 -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 tTCfO_2k46YW for ; Thu, 28 Sep 2017 07:06:41 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 650D71321A1 for ; Thu, 28 Sep 2017 07:06:39 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id 54so2889054wrz.10 for ; Thu, 28 Sep 2017 07:06: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=SKSO/7FUKQs7AqR3g0jzAAS3qpr3eWk/e6zlW1ggr6k=; b=aM2ck7I1uzgAnkV7axawTUVROyh57SCQEo7Rn1zmp55gbXL4RTdRnYoUAJK2MT+Pki TSn9p80S/YNkFLStUDGy49R2ZXFGTUmYHPP53FPHw3wYiFAJyX0RUXdAp6OF3EsY6vn1 mHqzq47MnkHIQPBSE+KZX4aJAU6btR5T7M5h0aS80/TyjfstnRZMLZVFmv8pha9p3qeq stIJT0xYFJsOvwkBWQRb8fme9paXmagyhiTmRhwL3VwbgSvBGxw+sya751H7mHXB/F4i WSAYM24BA2qUwTfR7RV9Vsa93z84f7zB4XnKbEQ7tJXMeAIN2bdJ6xsyEyIqeEHC0K08 aYxg== 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=SKSO/7FUKQs7AqR3g0jzAAS3qpr3eWk/e6zlW1ggr6k=; b=eAGzfpLS5KPxWTuMYRfAEjhYLVQ153qrOGPtQPVs0KEcPUevE9+/CA1VaJW5EmyLHd +MV+rQOU7ppM80HRw6pmMMxoNMeZ7zKUjXJI+Jehw2f1r+ywy+eFpTTDGz6mDAikRHPe vZrS+kiWIqSxncvKNboUPTXuIajMkdS5RbeL5gAft2usbHXElHoaqT1LBw2e6e7XGj5B zLPBJYawUo2XGPbFNsBj4mN/mPbcoS938nRxs2qr14zs2Yw+CZ1J10ZLhZAeNznDJbYG 1TVUtQlv74loa6MFeydUq0jrFpXMfZOl6XIGTVnGDI2G9Wbf1YyDxIMjwAFEB1b/HtY4 y0CA== X-Gm-Message-State: AHPjjUgck1RiZ3vfp2MNNtX+jinRGteIRntXqnv9DEpnoXNMieh7nXiV rIi7xFiibZwN5qkJHu2soQVwNtbq2aAmaMYWrwQ3lA== X-Google-Smtp-Source: AOwi7QCEv2T9AHmcKLaLuqncFrGKAMMZdW2Xjuw0AAwu0AM3afssdsbA+Xg8raems+XMhhU19SvtTsgUXiGEHaxxUrw= X-Received: by 10.25.0.144 with SMTP id 138mr276478lfa.64.1506607597781; Thu, 28 Sep 2017 07:06:37 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.25 with HTTP; Thu, 28 Sep 2017 07:06:37 -0700 (PDT) In-Reply-To: <026001d337f8$b0c4f030$124ed090$@augustcellars.com> References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> <026001d337f8$b0c4f030$124ed090$@augustcellars.com> From: Daniel Migault Date: Thu, 28 Sep 2017 10:06:37 -0400 X-Google-Sender-Auth: lrp3KqJV8w1sAnTvkcQf2MdM01k Message-ID: To: Jim Schaad Cc: curdle Content-Type: multipart/alternative; boundary="001a113c9e0cae88be055a406a92" Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 14:06:46 -0000 --001a113c9e0cae88be055a406a92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for the feed backs. Please find my response in line. Yours, Daniel On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad wrote: > > 1. I would not use the phrase =E2=80=9CIn some ways=E2=80=9D. =E2=80= =9CIt uses the > assignments made by the document draft-ietf-curdle-pkix to prepopulate= the > table, including a pair of assignments made during discussions that di= d not > make the final draft.=E2=80=9D Delete sentence 2, put this in as a = new sentence > 3. > > Correct. "In some ways" resulted from a bad copy/ paste. I not sure I really get the sentence numbers. The current paragraph is as below. Ar eyou ok with it. The draft does not discuss any technical content. The draft describes the set of OIDs that have been donated. It uses the assignments made by the document draft-ietf-curdle-pkix to prepopulate the table, including a pair of assignments made during discussions that did not make the final draft. It also describes the creation of an IANA registry table, as well as update procedure for adding new entries which includes, parameters to provide, the review process to follow and the way the arc can be extended. > 1. > 2. As noted before, the instructions to deal with the reference to the > -03 draft are in the XML as a request to the RFC editor. > > The comment on the XML specifies the version of the CURDLE draft is version 3. The reference is in the informational reference.My understanding is that the final to become RFC will also be needed and that the v3 will not be the only reference used. I think this reference is missing in the normative reference. > > > 1. This registry does require Expert review per section 4.6 of RFC > 8126. > > I think that was the sense of my response to question 18. Is the text clearer ? Future allocation does not require Expert review, instead it uses "specification required". If you resubmit a new version please could you changethe file name to draft-ietf-curdle.... > > > Jim > > > > > > *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *D= aniel > Migault > *Sent:* Wednesday, September 27, 2017 12:08 PM > *To:* Russ Housley > *Cc:* Jim Schaad ; curdle ; Sean > Turner > > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Thanks. It is better to be explicit and complete.These have been addresse= d. > > Yours, > > Daniel > > > > > > On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley > wrote: > > Daniel Migault is the document shepherd and Eric Rescorla is the responsi= ble Area. > > s/Area/Area Director/ > > > > Some questions do not have answers: (8), (13), (15) > > > > Russ > > > > > > On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: > > > > Hi, > > Please find the shepherd write up: > > > > https://datatracker.ietf.org/doc/draft-schaad-curdle-oid- > registry/shepherdwriteup/ > > > > Feel free to comment, by the end of the week. > > > > Yours, > > Daniel > > > > Small comments: > > a) > > [I-D.ietf-curdle-pkix ] should also be added as normative = and > [I-D.ietf-curdle-pkix -3] as informational. I think the no= rmative comment is missing > > Maybe a note to the editor should be added. We need to avoid the RFC bein= g in the informational reference ;-) > > b) the draft may be named ietf-curdle-oid-registry to reflect a WG docume= nt > > c) title of section 2.1 may be removed and all its content placed in sect= ion 2 > > d) If that is possible would it be possible to indicate the exact locatio= n where the > table is expected to be added. Currently my understanding is that it is n= ot possible, > but once the table will be added you will be 1) more specific and 2) add = a link as an > informal reference. > > > > On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad wrote= : > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Thursday, June 8, 2017 12:55 PM > *To:* Sean Turner > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Hi, > > Thank you for updating the draft Jim and Rick. While reviewing the draft > for the shepherd -write up I came with a few comments/questions. Please > find my comments below. > > Yours, > > Daniel > > > > COMMENT A) > > The type of the draft is currently "informational". According to RFC 2026 > I am more incline to consider that BCP would be more appropriated. Any > thoughts on that ? > > The draft does not discuss any technical content. The draft describes the > set of OIDs that have been donated. In some ways, it also assigns OIDs th= at > have not been assigned by any other RFCs ( but only version-03 of the pki= x > draft). It also describes the creation of an IANA registry table, as well > as update procedure for adding new entries which includes, parameters to > provide, the review process to follow and the way the arc can be extended= . > > In that sense according to RFC2026 the document is essentially documentin= g > IETF operations and so BCP seems the appropriated type. > > [JLS] I am not sure how you would presume that this could be a BCP? What > practices are we recommending that be followed? I think that this makes > far more sense as informational. There is nothing that says that an > informational draft be technical. Lots of informational drafts are about > procedures or about thought processes. I would keep this where it is. > > > > COMMENT B) > > It might my fault as I commented on the earlier version the references [ > I-D.ietf-curdle-pkix > ] > for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs > reserved for a specific Description while not being assigned. As we have > the intention to keep these OIDs, I think you opened a better path to hav= e > a RFC as a reference than having an old version of a draft. > > I interpret the the following text as explaining why we ended up with > id-EdDSA25516-ph and id-EdDSA448-ph. > > """ > > After those registrations were > > done, there were still some unused values that can be used for other > > security groups, there were still some unused values. > """ > > > Placing the current document as the Reference would clarify, in my > opinion, the status of these OIDs. It may be useful to add some text that > provides more explication with an reference to [I-D.ietf-curdle-pkix > ]-03. > As the RFC editor will probably replace [I-D.ietf-curdle-pkix > ] > with the RFC number, It might also be better to have a specific > informational reference. > > [JLS] There is a request in the XML that the RFC editor make sure that > this specific reference point to the version of the ID and not the RFC. > However, it gets messy if you have [draft] and [draft-3] I the same > document as well. Visually, it is currently a hard thing to do. > > COMMENT C) > > The draft says: > > """ > > IANA is asked to create one new registry table. > > 2.1 > . > "SMI Security for Cryptographic Algorithms" Registry > > > > Within the SMI-numbers registry, add an "SMI Security for > > Cryptographic Algorithms" table with the three columns: > > """ > > Maybe we should also specify that the SMI Security for Cryptographic > Algorithm registry is a sub-item of the "SMI Security Codes Registries". > > > I believe it would be useful to have an URL as an informational reference > for both the "SMI-numbers registry" as well as for "SMI Security Codes > Registries". > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml > https://www.iana.org/assignments/smi-numbers/smi- > numbers.xhtml#smi-numbers-26 > > Although I am not aware of a registration procedure for these tables and > the current, I believe it would be useful to specify explicitly all field= s > associated to the table. > > - Registration: Procedure Although it can be inferred from the curren= t > text. I believe it is helpful to the IANA to have the exact filed value > associated to all fields. > > - Description: The description is usually the arc ID, maybe in our > case we should add the range of provided OIDs. > > - Reference: It seems to me that the current document would be > appropriated. > > - Expert: The Registration Procedure mentions Expert review. I am not > sure experts should be listed in the in the RFC RFC5226 appointed by > IESG. > > > > [JLS] This is really a bit of a mess, because it does not really belong > under the SMI Security Codes section if one were being string. It is not > prefixed with the OID defined for that section. It is unfortunate that > Russ had all of the PKIX and S/MIME registries placed below that section. > However using the registry template associated with that would not really > be correct. I may talk to IANA during the process of final registration = to > see if we can create a new header and move all of the registries into tha= t > new header but I don=E2=80=99t want to do that as part of this document a= s it > probably would be messy to state. This type of decision is normally made > on the fly during the registration process and is not normally called out > explicitly. > > > > Experts are normally suggested by the authors, chairs or shepherds of the > document during the IESG review process at the request of the AD. > > > > We will end up with an entry that looks like https://www.iana.org/ > assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 which provides > a template of what is defined here. > > > > jim > > > > > > > > On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner wrote: > > I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s go= ing to do and > it=E2=80=99s pretty darn short and straight forward. Ship it! > > spt > > > > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > > > Hi, > > > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The > draft received significant comments during the WG adoption and is expecte= d > to be close to its final version. Please provide your feed backs by June = 16. > > > > Yours, > > Rich and Daniel > > > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a113c9e0cae88be055a406a92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

Thanks for the feed b= acks. Please find my response in line.

Yours,
Daniel=

On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad <ietf@augustcellar= s.com> wrote:
  1. I would= not use the phrase =E2=80=9CIn some ways=E2=80=9D.=C2=A0 =E2=80=9CIt uses = the assignments made by the document draft-ietf-curdle-pkix to prepopulate = the table, including a pair of assignments made during discussions that did= not make the final draft.=E2=80=9D=C2=A0=C2=A0=C2=A0 Delete sentence 2, pu= t this in as a new sentence 3.
Corre= ct. "In some ways" resulted from a bad copy/ paste. I not sure I = really get the sentence numbers. The current paragraph is as below. Ar eyou= ok with it.
The draft does not discuss any technical conten= t. The draft describes
the set of OIDs that have been donated. It uses = the assignments made
=C2=A0by the document draft-ietf-curdle-pkix to pre= populate the table, including
=C2=A0a pair of assignments made during di= scussions that did not make the
final draft. It also describes the crea= tion of an IANA registry table,
as well as update procedure for adding = new entries which includes,
parameters to provide, the review process t= o follow and the way the arc
can be extended.


  2. As noted before, the instructions to deal with the reference to the -03 d= raft are in the XML as a request to the RFC editor.
=C2=A0The comment on the XML specifies the version of the C= URDLE draft is version 3. The reference is in the informational reference.M= y understanding is that the final to become RFC will also be needed and tha= t the v3 will not be the only reference used. I think this reference is mis= sing in the normative reference.=C2=A0
=C2=A0
    This registry does require Expert review per section 4.6 of RFC 8126= .
I think that was the sense of my r= esponse to question 18. Is the text clearer ?

Fut= ure allocation does not require Expert review, instead it uses "specif= ication required".=C2=A0


If yo= u resubmit a new version please could you changethe file name to draft-ietf= -curdle....

=C2=A0

Jim

=C2=A0

=C2=A0

From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of Daniel Migault<= br>Sent: Wednesday, September 27, 2017 12:08 PM
To: Russ H= ousley <housle= y@vigilsec.com>
Cc: Jim Schaad <ietf@augustcellars.com>; curdle= <curdle@ietf.org>; Sean Turner <sean@sn3rd.com>


Subject:= Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

=C2=A0

Thanks. It= is better to be explicit and complete.These have been addressed.=

Yours,

Daniel

=C2=A0

= =C2=A0

On Wed, Sep 27, 2017 at 3:01 P= M, Russ Housley <housley@vigilsec.com> wrote:

Daniel Mig=
ault is the document shepherd and Eric Rescorla is the responsible Area.

s/Area/Area Director/<= u>

=C2=A0

<= div>

Some questions do not have answers: (8), (13), (= 15)

=C2=A0

Russ

=C2=A0

=C2=A0

On = Sep 27, 2017, at 2:56 PM, Daniel Migault <daniel.migault@ericsson.com> wrot= e:

=C2=A0

= Hi,

Please find the shepherd= write up:

=C2=A0=

=C2=A0

Feel free t= o comment, by the end of the week.

=C2=A0

Yours= ,

Daniel<= /p>

=C2=A0

Small comments:

a)

[I-D.ietf-curdle-pkix] should also be added as normative and 
[I-D.ietf-curdle-pkix-3] as info=
rmational. I think the normative comment is missing
Maybe a note to the editor should be added. We need to avoid the RFC being= in the informational reference ;-)
b) the draft may be named ietf-curdle-oid-registry to reflect=
 a WG document
c) titl=
e of section 2.1 may be removed and all its content placed in section 2<=
/u>
d) If that is possible wo=
uld it be possible to indicate the exact location where the 
table is ex=
pected to be added. Currently my understanding is that it is not possible, =

but once the table will be added you will be 1) more specific and 2) ad=
d a link as an
=C2=A0informal reference.

=C2=A0

On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> wrote:=

=C2=A0

=C2=A0

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

=C2= =A0

Hi,

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

=

Yours,

Daniel

=C2=A0

COMMENT A)

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

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

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

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

=C2=A0

COMMENT B= )

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

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

"""

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

=C2=A0=C2=A0 security groups, there were still some u=
nused values.
"""


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

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

COMMENT C)

T= he draft says:

"""

IANA is aske=
d to create one new registry table.

2.1<= /span>.=C2=A0 "= ;SMI Security for Cryptographic Algorithms" Registry<= /u>

=C2=A0
Within the SMI-numbers registry=
, add an "SMI Security for
Cryptographic Algor=
ithms" table with the three columns:

"""

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


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

https://www.iana.org/assignments/smi-numbers= /smi-numbers.xhtml
https://www= .iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-2= 6

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

=C2=A0=C2=A0=C2=A0 - Registr= ation: Procedure Although it can be inferred from the current text. I belie= ve it is helpful to the IANA to have the exact filed value associated to al= l fields.

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

=C2=A0=C2=A0=C2=A0 - Reference: It seems to me tha= t the current document would be appropriated.

<= p class=3D"MsoNormal">=C2=A0 =C2=A0 - Expert: The Registration Procedure me= ntions Expert review. I am not sure experts should be listed in the in the = RFC RFC5226=C2=A0 appointed by IESG.=C2=A0

=C2=A0

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

=C2=A0=

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

=C2=A0

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

=C2=A0

jim<= /u>

=C2=A0

=C2=A0

=C2=A0

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

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

spt

<= p class=3D"MsoNormal">
> On Jun 2, 2017, at 16:39, Daniel Migault <= ;daniel.mi= gault@ericsson.com> wrote:
>
> Hi,
>
> This = email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The draft= received significant comments during the WG adoption and is expected to be= close to its final version. Please provide your feed backs by June 16.
= >
> Yours,
> Rich and Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-<= wbr>registry/

> _______________________________________________
> Curd= le mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/cu= rdle

_______________________________________________
Cur= dle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle<= u>

=C2= =A0


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

=C2= =A0

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

=C2=A0


______________________________= _________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/<= wbr>listinfo/curdle

=C2=A0


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

--001a113c9e0cae88be055a406a92-- From nobody Thu Sep 28 07:37: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 CD3841331E7 for ; Thu, 28 Sep 2017 07:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sD2jusy5gSxu for ; Thu, 28 Sep 2017 07:36:57 -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 2FC2C133207 for ; Thu, 28 Sep 2017 07:36:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0296_01D3382C.8B2858B0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506609369; h=from:subject:to:date:message-id; bh=PyVROU7WcMbhdMyZGxLj3GJu+52DIL2+qLNbdFFt38g=; b=XlrJaTqqL2iccoqZsYxQXubBpSq8J6EXo2cEJOH40dgiI8EP+eMTijhhyhupX2s3EhRHZA7Gn6J AzdI1p9mgPi8Ei+GSoYFfwgJ3C7C0HrLKSxXxyQAFbijZR2kM+C8+qT65S8+fTM6loTZ8jtmMUYWQ Amnzh2OQ+6BKPgn3umGt54E2dWceGTHrwwzKBTIMoCem9k35PvaPoMF7LlJx23XCujqVE2ObS21RX yBRbjaBqxj2BoiJe6+rwCjVHC3oT0i/ctGUzce68dbovJjjp6wegvW0myxBVCNmpygFOtt/bBx/1J r++yInLNm1o5jqEOB6FKnKscYUL4m+y0y8eQ== 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, 28 Sep 2017 07:36:08 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 07:36:02 -0700 From: Jim Schaad To: 'Daniel Migault' CC: 'curdle' References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> <026001d337f8$b0c4f030$124ed090$@augustcellars.com> In-Reply-To: Date: Thu, 28 Sep 2017 07:36:45 -0700 Message-ID: <029501d33867$37818b60$a684a220$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb1xZwqGaWy4iJzjCFcw91l4MwcAKUrU/kAn9JjwACxKIGkAHJEGYKAsAQmu4DfUDCtgMpxS6CAg3oePOhEGkN0A== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 14:37:02 -0000 ------=_NextPart_000_0296_01D3382C.8B2858B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault Sent: Thursday, September 28, 2017 7:07 AM To: Jim Schaad Cc: curdle Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Hi Jim,=20 Thanks for the feed backs. Please find my response in line. Yours,=20 Daniel =20 On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad > wrote: 1. I would not use the phrase =E2=80=9CIn some ways=E2=80=9D. = =E2=80=9CIt uses the assignments made by the document = draft-ietf-curdle-pkix to prepopulate the table, including a pair of = assignments made during discussions that did not make the final = draft.=E2=80=9D Delete sentence 2, put this in as a new sentence 3. Correct. "In some ways" resulted from a bad copy/ paste. I not sure I = really get the sentence numbers. The current paragraph is as below. Ar = eyou ok with it.=20 The draft does not discuss any technical content. The draft describes=20 the set of OIDs that have been donated. It uses the assignments made by the document draft-ietf-curdle-pkix to prepopulate the table, = including a pair of assignments made during discussions that did not make the=20 final draft. It also describes the creation of an IANA registry table,=20 as well as update procedure for adding new entries which includes,=20 parameters to provide, the review process to follow and the way the arc can be extended. =20 [JLS] I would describe the creation before the population. That is why = I suggested change the sentence order. =20 1. =20 2. As noted before, the instructions to deal with the reference to the = -03 draft are in the XML as a request to the RFC editor. The comment on the XML specifies the version of the CURDLE draft is = version 3. The reference is in the informational reference.My = understanding is that the final to become RFC will also be needed and = that the v3 will not be the only reference used. I think this reference = is missing in the normative reference. =20 =20 [JLS] Currently both of those references are informational. I think = this is correct as one does not need to understand the content there in = order to understand what is happening in this draft. If you really want = them to be normative that is a problem because of the down ref to -03. = I think they should both be at the same level. 1. This registry does require Expert review per section 4.6 of RFC 8126. I think that was the sense of my response to question 18. Is the text = clearer ? =20 Future allocation does not require Expert review, instead it uses = "specification required".=20 =20 [JLS] RFC 8126 says =E2=80=9CFor the Specification Required policy, = review and approval by a designated expert (see Section 5 = ) is required=E2=80=9D = This text says that an expert review is required even if the policy is = specification required. =20 =20 =20 If you resubmit a new version please could you changethe file name to = draft-ietf-curdle....=20 =20 Jim =20 =20 From: mglt.ietf@gmail.com = [mailto:mglt.ietf@gmail.com ] On Behalf Of = Daniel Migault Sent: Wednesday, September 27, 2017 12:08 PM To: Russ Housley > Cc: Jim Schaad = >; curdle >; Sean Turner = > Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Thanks. It is better to be explicit and complete.These have been = addressed. Yours,=20 Daniel =20 =20 On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley > wrote: Daniel Migault is the document shepherd and Eric Rescorla is the = responsible Area.=20 s/Area/Area Director/ =20 Some questions do not have answers: (8), (13), (15) =20 Russ =20 =20 On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: =20 Hi,=20 Please find the shepherd write up: =20 https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepher= dwriteup/ =20 Feel free to comment, by the end of the week.=20 =20 Yours,=20 Daniel =20 Small comments: a) [I-D.ietf-curdle-pkix = ] should also be added as normative and=20 [I-D.ietf-curdle-pkix = -3] as informational. I think the normative comment is = missing Maybe a note to the editor should be added. We need to avoid the RFC = being in the informational reference ;-) b) the draft may be named ietf-curdle-oid-registry to reflect a WG = document c) title of section 2.1 may be removed and all its content placed in = section 2 d) If that is possible would it be possible to indicate the exact = location where the=20 table is expected to be added. Currently my understanding is that it is = not possible,=20 but once the table will be added you will be 1) more specific and 2) add = a link as an informal reference.=20 =20 On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad > wrote: =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Daniel Migault Sent: Thursday, June 8, 2017 12:55 PM To: Sean Turner > Cc: curdle > Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Hi,=20 Thank you for updating the draft Jim and Rick. While reviewing the draft = for the shepherd -write up I came with a few comments/questions. Please = find my comments below. Yours,=20 Daniel =20 COMMENT A)=20 The type of the draft is currently "informational". According to RFC = 2026 I am more incline to consider that BCP would be more appropriated. = Any thoughts on that ? The draft does not discuss any technical content. The draft describes = the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 = of the pkix draft). It also describes the creation of an IANA registry = table, as well as update procedure for adding new entries which = includes, parameters to provide, the review process to follow and the = way the arc can be extended.=20 In that sense according to RFC2026 the document is essentially = documenting IETF operations and so BCP seems the appropriated type. [JLS] I am not sure how you would presume that this could be a BCP? = What practices are we recommending that be followed? I think that this = makes far more sense as informational. There is nothing that says that = an informational draft be technical. Lots of informational drafts are = about procedures or about thought processes. I would keep this where it = is. =20 COMMENT B)=20 It might my fault as I commented on the earlier version the references = [I-D.ietf-curdle-pkix = ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks = confusing to have OIDs reserved for a specific Description while not = being assigned. As we have the intention to keep these OIDs, I think you = opened a better path to have a RFC as a reference than having an old = version of a draft.=20 I interpret the the following text as explaining why we ended up with = id-EdDSA25516-ph and id-EdDSA448-ph.=20 """ After those registrations were done, there were still some unused values that can be used for other security groups, there were still some unused values. """ Placing the current document as the Reference would clarify, in my = opinion, the status of these OIDs. It may be useful to add some text = that provides more explication with an reference to = [I-D.ietf-curdle-pkix = ]-03. As the RFC editor will probably replace = [I-D.ietf-curdle-pkix = ] with the RFC number, It might also be better to have = a specific informational reference. =20 [JLS] There is a request in the XML that the RFC editor make sure that = this specific reference point to the version of the ID and not the RFC. = However, it gets messy if you have [draft] and [draft-3] I the same = document as well. Visually, it is currently a hard thing to do. COMMENT C) The draft says: """ IANA is asked to create one new registry table. = 2.1. "SMI Security for Cryptographic Algorithms" Registry =20 Within the SMI-numbers registry, add an "SMI Security for Cryptographic Algorithms" table with the three columns: """ Maybe we should also specify that the SMI Security for Cryptographic = Algorithm registry is a sub-item of the "SMI Security Codes Registries". = I believe it would be useful to have an URL as an informational = reference for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".=20 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-26 Although I am not aware of a registration procedure for these tables and = the current, I believe it would be useful to specify explicitly all = fields associated to the table.=20 - Registration: Procedure Although it can be inferred from the = current text. I believe it is helpful to the IANA to have the exact = filed value associated to all fields.=20 - Description: The description is usually the arc ID, maybe in our = case we should add the range of provided OIDs. - Reference: It seems to me that the current document would be = appropriated. - Expert: The Registration Procedure mentions Expert review. I am = not sure experts should be listed in the in the RFC RFC5226 appointed = by IESG. =20 =20 [JLS] This is really a bit of a mess, because it does not really belong = under the SMI Security Codes section if one were being string. It is = not prefixed with the OID defined for that section. It is unfortunate = that Russ had all of the PKIX and S/MIME registries placed below that = section. However using the registry template associated with that would = not really be correct. I may talk to IANA during the process of final = registration to see if we can create a new header and move all of the = registries into that new header but I don=E2=80=99t want to do that as = part of this document as it probably would be messy to state. This type = of decision is normally made on the fly during the registration process = and is not normally called out explicitly. =20 Experts are normally suggested by the authors, chairs or shepherds of = the document during the IESG review process at the request of the AD.=20 =20 We will end up with an entry that looks like = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-s= mime-3 which provides a template of what is defined here. =20 jim =20 =20 =20 On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner > wrote: I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! spt > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > Hi, > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16. > > Yours, > Rich and Daniel > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > _______________________________________________ > Curdle mailing list > Curdle@ietf.org =20 > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_0296_01D3382C.8B2858B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault
Sent: Thursday, September 28, 2017 7:07 = AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: = curdle <curdle@ietf.org>
Subject: Re: [Curdle] WGLC = draft-schaad-curdle-oid-registry

 

Hi Jim, =

Thanks for the feed backs. Please find my = response in line.

Yours, =

Daniel

 

On Wed, = Sep 27, 2017 at 9:25 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

  1. I would not use the phrase =E2=80=9CIn some = ways=E2=80=9D.  =E2=80=9CIt uses the assignments made by the = document draft-ietf-curdle-pkix to prepopulate the table, including a = pair of assignments made during discussions that did not make the final = draft.=E2=80=9D    Delete sentence 2, put this in as a = new sentence 3.

Correct. "In some ways" resulted from a bad = copy/ paste. I not sure I really get the sentence numbers. The current = paragraph is as below. Ar eyou ok with it.

The draft does not discuss any technical content. The = draft describes
the set of OIDs that have been donated. It uses the = assignments made
 by the document draft-ietf-curdle-pkix to = prepopulate the table, including
 a pair of assignments made = during discussions that did not make the
final draft. It also = describes the creation of an IANA registry table,
as well as update = procedure for adding new entries which includes,
parameters to = provide, the review process to follow and the way the arc
can be = extended.

 

[JLS] I would describe the creation before the = population.=C2=A0 That is why I suggested change the sentence = order.

 

  1.  
  2. As noted before, the instructions to deal = with the reference to the -03 draft are in the XML as a request to the = RFC editor.

 The comment on the XML specifies the version of = the CURDLE draft is version 3. The reference is in the informational = reference.My understanding is that the final to become RFC will also be = needed and that the v3 will not be the only reference used. I think this = reference is missing in the normative reference.  =

 

[JLS]=C2=A0 Currently both of those references = are informational.=C2=A0 I think this is correct as one does not need to = understand the content there in order to understand what is happening in = this draft.=C2=A0 If you really want them to be normative that is a = problem because of the down ref to -03.=C2=A0 I think they should both = be at the same level.

  1. This registry does require Expert review per = section 4.6 of RFC = 8126.

I think that was the sense of my response to question = 18. Is the text clearer ?

 

Future allocation does not require Expert review, = instead it uses "specification = required". 

 

[JLS] RFC 8126 =
says =E2=80=9CFor the Specification Required policy, review and =
approval by a designated expert (see Section 5) is =
required=E2=80=9D=C2=A0 This text says =
that an expert review is required even if the policy is specification =
required.

 

 

 

If you resubmit a new version please could you = changethe file name to draft-ietf-curdle.... =

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

From:= mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of Daniel = Migault
Sent: Wednesday, September 27, 2017 12:08 = PM
To: Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad = <ietf@augustcellars.com>; curdle <curdle@ietf.org>; Sean Turner <sean@sn3rd.com>


Subject: Re: [Curdle] WGLC = draft-schaad-curdle-oid-registry

 <= /o:p>

Thanks. It = is better to be explicit and complete.These have been = addressed.

Yours, =

Daniel<= /o:p>

 <= /o:p>

 <= /o:p>

On Wed, Sep = 27, 2017 at 3:01 PM, Russ Housley <housley@vigilsec.com> = wrote:

Daniel Migault is the document shepherd and =
Eric Rescorla is the responsible Area.

s/Area/Area = Director/

 <= /o:p>

Some = questions do not have answers: (8), (13), = (15)

 

Russ

 <= /o:p>

 <= /o:p>

On Sep 27, = 2017, at 2:56 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:

 <= /o:p>

Hi, =

Please find = the shepherd write up:

 <= /o:p>

 <= /o:p>

Feel free = to comment, by the end of the week.

 <= /o:p>

Yours, =

Daniel<= /o:p>

 <= /o:p>

Small = comments:

a)

[I-D.ietf-curdle-pkix] =
should also be added as normative and 
[I-D.ietf-curdle-pkix-3] =
as informational. I think the normative comment is =
missing
Maybe a note to the editor should be added. =
We need to avoid the RFC being in the informational reference =
;-)
b) the draft may =
be named ietf-curdle-oid-registry to reflect a WG =
document
c) title of =
section 2.1 may be removed and all its content placed in section =
2
d) If that is =
possible would it be possible to indicate the exact location where the =

table is expected to be added. Currently my understanding is that it =
is not possible, 
but once the table will be added you will be 1) =
more specific and 2) add a link as an
 informal reference. =

 <= /o:p>

On Thu, Jun = 8, 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 <= /o:p>

 <= /o:p>

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

 <= /o:p>

Hi, =

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

Yours, =

Daniel<= /o:p>

 <= /o:p>

COMMENT A) =

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

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

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

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

 <= /p>

COMMENT B) =

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

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

"""

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


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

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

COMMENT = C)

The draft = says:

"""

IANA is asked to =
create one new registry table.

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

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

""= "

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


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

https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml
https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml#smi-numbers-26

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

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

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

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

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

 <= /o:p>

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

 

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

 

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

 

jim

  =

  =

 <= /o:p>

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

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

spt


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

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

 <= /o:p>


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

 <= /o:p>

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

 <= /o:p>


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

 <= /o:p>


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

 

------=_NextPart_000_0296_01D3382C.8B2858B0-- From nobody Thu Sep 28 10:35: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 EE0DE132D41 for ; Thu, 28 Sep 2017 10:35:38 -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 mffTS2xSMZJT for ; Thu, 28 Sep 2017 10:35:35 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177C0132125 for ; Thu, 28 Sep 2017 10:35:35 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id 54so4006704wrz.10 for ; Thu, 28 Sep 2017 10:35:35 -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=E77D9/aS6Tfj0gdMdgmsjNuYkBfxSuFJYLcFtJXHj54=; b=CBYCNVQCj3bEjlThD1modgtF8YMz25YTXNhv3Pgmlfy8f1qz10BuQ8ddWxlneXjts3 GgDamMDxalAV6jHhFuWSeH7j9xqXcT9ZBsk7CGT9Io4ff3DkvkbIR1c4vPxtOGqXeaRS f7FSgRaovI7F9yjPcR2Y+0w96kGDNQLkAozVnkZ8/VURBQpR7TXAkmoiXfWwFQjddBVB USP/HelwuhsgC+Nom9ZSVM9M0AfxVodLO/2X4rQX9cRk6lKGN/EUx1qLpqgaXNyFoIeR LtZljh+Z1VvIdQVHXnE2KJSwkTqUpQ2QqQUzWT9w9iG1UReRvkrs/r2pyY0NSQoxjZpJ +dCw== 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=E77D9/aS6Tfj0gdMdgmsjNuYkBfxSuFJYLcFtJXHj54=; b=DtuxSTAmenZko0ELzuG7LVp7XS5ZQ2PbiZLJ5fJIQoYqT82U99eIXSGZKiE6ZvRakF 7Oixz12TuEs5M/tmg++/E2Ni6E4FVTywxsrzXBDU0mNFgvzhqSYEVggeApjf8tlRyS69 CDOAMHU3TjUGeF7H95kfjrda09TZDxyADCnUjzG0E4z+/YiUogA5SdPxo2n7OmZ3/ARv QwyFsoJY1DkYKNxxb2WfMGXRQmi4JSmvUZ5dNnZ1cKnxOGoA/1Iansu0iAWiw0QEnLi3 jwNmSvNO3hbPjsaDeu2Zywz5s6iJfR1kJz9QEK0Zz59/7onb/xdFPVVv9Gj5LfUL0Ffq B9Bg== X-Gm-Message-State: AHPjjUhIFAk4CnN6yPV4GH/A5wIne3BbW0DAppkh42G2+4kFMKwUwgU4 oU04/T1Mi8cEtBK2405xdTkrTbl6ZOaKhNhUYTYbnA== X-Google-Smtp-Source: AOwi7QDEqbugt3lUA13o44zkFig/sqOrdn1Hg3sI5b8SqYc+G45eZ376ZZ5uIQdkVBLXdDGjkzWHhXp5/nfBI6iC7R8= X-Received: by 10.46.3.1 with SMTP id 1mr2407740ljd.147.1506620133541; Thu, 28 Sep 2017 10:35:33 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.25 with HTTP; Thu, 28 Sep 2017 10:35:32 -0700 (PDT) In-Reply-To: <029501d33867$37818b60$a684a220$@augustcellars.com> References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> <026001d337f8$b0c4f030$124ed090$@augustcellars.com> <029501d33867$37818b60$a684a220$@augustcellars.com> From: Daniel Migault Date: Thu, 28 Sep 2017 13:35:32 -0400 X-Google-Sender-Auth: Zrnj8ISVS1Ck9XcXffdl78nRmF4 Message-ID: To: Jim Schaad Cc: curdle Content-Type: multipart/alternative; boundary="089e082756b8df0d18055a435513" Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 17:35:39 -0000 --089e082756b8df0d18055a435513 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, I think the current write-up address your comment. Let me know if that is fine to you, so I can press the button. Yours, Daniel On Thu, Sep 28, 2017 at 10:36 AM, Jim Schaad wrote= : > > > > > *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *D= aniel > Migault > *Sent:* Thursday, September 28, 2017 7:07 AM > *To:* Jim Schaad > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Hi Jim, > > Thanks for the feed backs. Please find my response in line. > > Yours, > > Daniel > > > > On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad > wrote: > > > 1. I would not use the phrase =E2=80=9CIn some ways=E2=80=9D. =E2=80= =9CIt uses the > assignments made by the document draft-ietf-curdle-pkix to prepopulate= the > table, including a pair of assignments made during discussions that di= d not > make the final draft.=E2=80=9D Delete sentence 2, put this in as a = new sentence > 3. > > Correct. "In some ways" resulted from a bad copy/ paste. I not sure I > really get the sentence numbers. The current paragraph is as below. Ar ey= ou > ok with it. > > The draft does not discuss any technical content. The draft describes > the set of OIDs that have been donated. It uses the assignments made > by the document draft-ietf-curdle-pkix to prepopulate the table, includi= ng > a pair of assignments made during discussions that did not make the > final draft. It also describes the creation of an IANA registry table, > as well as update procedure for adding new entries which includes, > parameters to provide, the review process to follow and the way the arc > can be extended. > > > > [JLS] I would describe the creation before the population. That is why I > suggested change the sentence order. > The current text is: The draft does not discuss any technical content. The draft describes the set of OIDs that have been donated. It also describes the creation of an IANA registry table, as well as update procedure for adding new entries which includes, parameters to provide, the review process to follow and the way the arc can be extended. It uses the assignments made by the document draft-ietf-curdle-pkix to prepopulate the table, including a pair of assignments made during discussions that did not make the final draft. I think that address your comment. > > > 1. > 2. As noted before, the instructions to deal with the reference to the > -03 draft are in the XML as a request to the RFC editor. > > The comment on the XML specifies the version of the CURDLE draft is > version 3. The reference is in the informational reference.My understandi= ng > is that the final to become RFC will also be needed and that the v3 will > not be the only reference used. I think this reference is missing in the > normative reference. > > > > [JLS] Currently both of those references are informational. I think thi= s > is correct as one does not need to understand the content there in order = to > understand what is happening in this draft. If you really want them to b= e > normative that is a problem because of the down ref to -03. I think they > should both be at the same level. > > Actually, I expected RFC to be normative and -03 to be informational, I even did not thought of having the RFC as informational... As this is intentional, I will describe this in the shepherd write up and let the AD come back if he prefer otherwise. At least I understand your position now. Thanks. > > 1. This registry does require Expert review per section 4.6 of RFC > 8126. > > I think that was the sense of my response to question 18. Is the text > clearer ? > > > > Future allocation does not require Expert review, instead it uses > "specification required". > > > > [JLS] RFC 8126 says =E2=80=9CFor the Specification Required policy, revie= w and approval by a designated expert (see Section 5 ) is required=E2=80=9D This text says that an exp= ert review is required even if the policy is specification required. > > > thanks for the correction. > > > > > If you resubmit a new version please could you changethe file name to > draft-ietf-curdle.... > > > > Jim > > > > > > *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *D= aniel > Migault > *Sent:* Wednesday, September 27, 2017 12:08 PM > *To:* Russ Housley > *Cc:* Jim Schaad ; curdle ; Sean > Turner > > > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Thanks. It is better to be explicit and complete.These have been addresse= d. > > Yours, > > Daniel > > > > > > On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley > wrote: > > Daniel Migault is the document shepherd and Eric Rescorla is the responsi= ble Area. > > s/Area/Area Director/ > > > > Some questions do not have answers: (8), (13), (15) > > > > Russ > > > > > > On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: > > > > Hi, > > Please find the shepherd write up: > > > > https://datatracker.ietf.org/doc/draft-schaad-curdle-oid- > registry/shepherdwriteup/ > > > > Feel free to comment, by the end of the week. > > > > Yours, > > Daniel > > > > Small comments: > > a) > > [I-D.ietf-curdle-pkix ] should also be added as normative = and > [I-D.ietf-curdle-pkix -3] as informational. I think the no= rmative comment is missing > > Maybe a note to the editor should be added. We need to avoid the RFC bein= g in the informational reference ;-) > > b) the draft may be named ietf-curdle-oid-registry to reflect a WG docume= nt > > c) title of section 2.1 may be removed and all its content placed in sect= ion 2 > > d) If that is possible would it be possible to indicate the exact locatio= n where the > table is expected to be added. Currently my understanding is that it is n= ot possible, > but once the table will be added you will be 1) more specific and 2) add = a link as an > informal reference. > > > > On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad wrote= : > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Thursday, June 8, 2017 12:55 PM > *To:* Sean Turner > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry > > > > Hi, > > Thank you for updating the draft Jim and Rick. While reviewing the draft > for the shepherd -write up I came with a few comments/questions. Please > find my comments below. > > Yours, > > Daniel > > > > COMMENT A) > > The type of the draft is currently "informational". According to RFC 2026 > I am more incline to consider that BCP would be more appropriated. Any > thoughts on that ? > > The draft does not discuss any technical content. The draft describes the > set of OIDs that have been donated. In some ways, it also assigns OIDs th= at > have not been assigned by any other RFCs ( but only version-03 of the pki= x > draft). It also describes the creation of an IANA registry table, as well > as update procedure for adding new entries which includes, parameters to > provide, the review process to follow and the way the arc can be extended= . > > In that sense according to RFC2026 the document is essentially documentin= g > IETF operations and so BCP seems the appropriated type. > > [JLS] I am not sure how you would presume that this could be a BCP? What > practices are we recommending that be followed? I think that this makes > far more sense as informational. There is nothing that says that an > informational draft be technical. Lots of informational drafts are about > procedures or about thought processes. I would keep this where it is. > > > > COMMENT B) > > It might my fault as I commented on the earlier version the references [ > I-D.ietf-curdle-pkix > ] > for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs > reserved for a specific Description while not being assigned. As we have > the intention to keep these OIDs, I think you opened a better path to hav= e > a RFC as a reference than having an old version of a draft. > > I interpret the the following text as explaining why we ended up with > id-EdDSA25516-ph and id-EdDSA448-ph. > > """ > > After those registrations were > > done, there were still some unused values that can be used for other > > security groups, there were still some unused values. > """ > > > Placing the current document as the Reference would clarify, in my > opinion, the status of these OIDs. It may be useful to add some text that > provides more explication with an reference to [I-D.ietf-curdle-pkix > ]-03. > As the RFC editor will probably replace [I-D.ietf-curdle-pkix > ] > with the RFC number, It might also be better to have a specific > informational reference. > > [JLS] There is a request in the XML that the RFC editor make sure that > this specific reference point to the version of the ID and not the RFC. > However, it gets messy if you have [draft] and [draft-3] I the same > document as well. Visually, it is currently a hard thing to do. > > COMMENT C) > > The draft says: > > """ > > IANA is asked to create one new registry table. > > 2.1 > . > "SMI Security for Cryptographic Algorithms" Registry > > > > Within the SMI-numbers registry, add an "SMI Security for > > Cryptographic Algorithms" table with the three columns: > > """ > > Maybe we should also specify that the SMI Security for Cryptographic > Algorithm registry is a sub-item of the "SMI Security Codes Registries". > > > I believe it would be useful to have an URL as an informational reference > for both the "SMI-numbers registry" as well as for "SMI Security Codes > Registries". > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml > https://www.iana.org/assignments/smi-numbers/smi- > numbers.xhtml#smi-numbers-26 > > Although I am not aware of a registration procedure for these tables and > the current, I believe it would be useful to specify explicitly all field= s > associated to the table. > > - Registration: Procedure Although it can be inferred from the curren= t > text. I believe it is helpful to the IANA to have the exact filed value > associated to all fields. > > - Description: The description is usually the arc ID, maybe in our > case we should add the range of provided OIDs. > > - Reference: It seems to me that the current document would be > appropriated. > > - Expert: The Registration Procedure mentions Expert review. I am not > sure experts should be listed in the in the RFC RFC5226 appointed by > IESG. > > > > [JLS] This is really a bit of a mess, because it does not really belong > under the SMI Security Codes section if one were being string. It is not > prefixed with the OID defined for that section. It is unfortunate that > Russ had all of the PKIX and S/MIME registries placed below that section. > However using the registry template associated with that would not really > be correct. I may talk to IANA during the process of final registration = to > see if we can create a new header and move all of the registries into tha= t > new header but I don=E2=80=99t want to do that as part of this document a= s it > probably would be messy to state. This type of decision is normally made > on the fly during the registration process and is not normally called out > explicitly. > > > > Experts are normally suggested by the authors, chairs or shepherds of the > document during the IESG review process at the request of the AD. > > > > We will end up with an entry that looks like https://www.iana.org/ > assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 which provides > a template of what is defined here. > > > > jim > > > > > > > > On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner wrote: > > I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s go= ing to do and > it=E2=80=99s pretty darn short and straight forward. Ship it! > > spt > > > > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > > > Hi, > > > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The > draft received significant comments during the WG adoption and is expecte= d > to be close to its final version. Please provide your feed backs by June = 16. > > > > Yours, > > Rich and Daniel > > > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > 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 > > --089e082756b8df0d18055a435513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

I think the current w= rite-up address your comment. Let me know if that is fine to you, so I can = press the button.

Yours,
Daniel
<= div>

On Thu, Sep 2= 8, 2017 at 10:36 AM, Jim Schaad <ietf@augustcellars.com> wrote:

=C2=A0

=C2=A0

From: mg= lt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of Daniel Migault
= Sent: Thursday, September 28, 2017 7:07 AM
To: Jim = Schaad <ietf= @augustcellars.com>
Cc: curdle <= curdle@ietf.org>= ;
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registr= y

=C2=A0<= u>

Hi Jim,

Thanks for the feed backs. Please fi= nd my response in line.

Yours,

Daniel

=C2=A0

On Wed, Sep 27, 2017 a= t 9:25 PM, Jim Schaad <ietf@augustcellars.com> wrote:

<= ol start=3D"1" type=3D"1">
  • I would not use the phrase =E2=80=9CIn some ways=E2=80=9D.=C2=A0 =E2=80=9C= It uses the assignments made by the document draft-ietf-curdle-pkix to prep= opulate the table, including a pair of assignments made during discussions = that did not make the final draft.=E2=80=9D=C2=A0=C2=A0=C2=A0 Delete senten= ce 2, put this in as a new sentence 3.
    • <= /blockquote>

    Correct. "In some ways" r= esulted from a bad copy/ paste. I not sure I really get the sentence number= s. The current paragraph is as below. Ar eyou ok with it.

    The draft does not discuss any technical= content. The draft describes
    the set of OIDs that have been donated. I= t uses the assignments made
    =C2=A0by the document draft-ietf-curdle-pkix= to prepopulate the table, including
    =C2=A0a pair of assignments made du= ring discussions that did not make the
    final draft. It also describes t= he creation of an IANA registry table,
    as well as update procedure for = adding new entries which includes,
    parameters to provide, the review pr= ocess to follow and the way the arc
    can be extended.

    =C2=A0

    [JLS] I would describe the = creation before the population.=C2=A0 That is why I suggested change the se= ntence order.

    <mglt>
    The current text is= :
    The draft does not discuss any technical content. The draft des= cribes
    the set of OIDs that have been donated.=C2=A0 It also describes = the creation
    of an IANA registry table, as well as update procedure for= adding new
    entries which includes, parameters to provide, the review pr= ocess to
    follow and the way the arc can be extended. It uses the assign= ments made
    =C2=A0by the document draft-ietf-curdle-pkix to prepopulate t= he table, including
    =C2=A0a pair of assignments made during discussions = that did not make the
    final draft.

    I think that addre= ss your comment.
    </mglt>

    =

    <= p class=3D"MsoNormal">=C2=A0

    1. =C2=A0<= u>
    2. As noted befor= e, the instructions to deal with the reference to the -03 draft are in the = XML as a request to the RFC editor.

    =C2=A0The comment on the XML specifies= the version of the CURDLE draft is version 3. The reference is in the info= rmational reference.My understanding is that the final to become RFC will a= lso be needed and that the v3 will not be the only reference used. I think = this reference is missing in the normative reference.=C2=A0 <= /p>

    =C2=A0

    [JLS]=C2=A0 Current= ly both of those references are informational.=C2=A0 I think this is correc= t as one does not need to understand the content there in order to understa= nd what is happening in this draft.=C2=A0 If you really want them to be nor= mative that is a problem because of the down ref to -03.=C2=A0 I think they= should both be at the same level.

    &l= t;mglt>Actually, I expected RFC to be normative and -03 to be informatio= nal, I even did not thought of having the RFC as informational... As this i= s intentional, I will describe this in the shepherd write up and let the AD= come back if he prefer otherwise. At least I understand your position now.= Thanks. </mglt>=C2=A0

    =

      This registry does require E= xpert review per section 4.6 of RFC 8126.

    I = think that was the sense of my response to question 18. Is the text clearer= ?

    =C2=A0<= /p>

    Future a= llocation does not require Expert review, instead it uses "specificati= on required".=C2=A0

    =C2= =A0

    [JLS] RFC 8126 says =E2=80=9CFor the =
Specification Required policy, review and approval by a designated expert (see Section 5) is required=E2=80=9D=
=C2=A0 This text says that an expert r=
eview is required even if the policy is specification required.

    = =C2=A0

    <mglt>thanks for the correction.<= /mglt>=C2=A0

    =

    =C2=A0

    =C2=A0

    If you resubmit a new version please could you changethe = file name to draft-ietf-curdle....

    =C2=A0

    Jim=

    =C2=A0

    =C2=A0

    From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com<= /a>] On Behalf Of Daniel Migault
    Sent: Wednesday, Septembe= r 27, 2017 12:08 PM
    To: Russ Housley <housley@vigilsec.com>
    Cc: Jim Schaad <ietf@augustcellars.com>; curdle <curdle@ietf.org>; Sean Turner <sean@sn3rd.com>


    Subject: Re: [Curdle] WGL= C draft-schaad-curdle-oid-registry

    =

    =C2=A0

    Thanks. It is better to be explicit and complete.= These have been addressed.

    Yo= urs,

    Daniel

    =C2=A0

    =C2=A0

    On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley <housley@vigilsec.com> wrote:<= u>

    Daniel Migault is the document shepherd and Eric Rescorla is =
the responsible Area.

    s/Are= a/Area Director/

    =C2=A0<= u>

    Some questions do not ha= ve answers: (8), (13), (15)

    =C2=A0

    <= /div>

    Rus= s

    =C2= =A0

    =C2=A0=

    =

    On Sep 27, 2017, at 2:56 PM, Daniel Migault <daniel.migault= @ericsson.com> wrote:

    = =C2=A0

    Hi,

    Please find the shepherd write up:

    =C2=A0

    https://datatracker.ietf.org/doc/d= raft-schaad-curdle-oid-registry/shepherdwriteup/

    =

    =C2=A0

    Feel free to comment, by the end of the week.

    =C2=A0

    =

    Yours,

    Daniel

    =C2=A0<= /u>

    Small comments:

    a)

    [I-D.ietf-curdle-pkix] should also be adde=
d as normative and 
    [I-D.iet=
f-curdle-pkix-3] as informational. I think the normative comment is mis=
sing
    Maybe a note to the editor should be added. We=
 need to avoid the RFC being in the informational reference ;-)
    b) the draft may be named ietf-cu=
rdle-oid-registry to reflect a WG document
    c) title of section 2.1 may be removed and all its con=
tent placed in section 2
    d) If that is possible would it be possible to indicate the exact locati=
on where the 
    table is expected to be added. Currently my understanding =
is that it is not possible, 
    but once the table will be added you will b=
e 1) more specific and 2) add a link as an
    =C2=A0informal reference. =

    =C2=A0

    On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaa= d <ietf@augu= stcellars.com> wrote:

    =C2=A0=

    =C2=A0

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

    =C2=A0

    Hi,

    <= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">Thank you for updating t= he draft Jim and Rick. While reviewing the draft for the shepherd -write up= I came with a few comments/questions.=C2=A0 Please find my comments below.=

    Yours,

    Daniel

    =C2=A0

    COMMENT A)

    The type of the draft is curren= tly "informational". According to RFC 2026 I am more incline to c= onsider that BCP would be more appropriated. Any thoughts on that ?<= u>

    Th= e draft does not discuss any technical content. The draft describes the set= of OIDs that have been donated. In some ways, it also assigns OIDs that ha= ve not been assigned by any other RFCs ( but only version-03 of the pkix dr= aft). It also describes the creation of an IANA registry table, as well as = update procedure for adding new entries which includes, parameters to provi= de, the review process to follow and the way the arc can be extended.
    <= br>In that sense according to RFC2026 the document is essentially documenti= ng IETF operations and so BCP seems the appropriated type.

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

    =C2=A0

    COMMENT B)

    It might my fault as I commented on the earlie= r version the references [I-D.i= etf-curdle-pkix] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks conf= using to have OIDs reserved for a specific Description while not being assi= gned. As we have the intention to keep these OIDs, I think you opened a bet= ter path to have a RFC as a reference than having an old version of a draft= .

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

    """= 

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

    Placing the current d=
ocument as the Reference would clarify, in my opinion, the status of these =
OIDs. It may be useful to add some text that provides more explication with=
 an reference to [I-D.ietf-curd=
le-pkix]-03. As the RFC editor will probably replace [I-D.ietf-curdle-pkix] with the RFC number, I=
t might also be better to have a specific informational reference.=C2=A0 =
=C2=A0 
    [JLS] There is a request in the XML =
that the RFC editor make sure that this specific reference point to the ver=
sion of the ID and not the RFC. However, it gets messy if you have [draft] =
and [draft-3] I the same document as well.=C2=A0 Visually, it is currently =
a hard thing to do.

    COMMENT C)

    The draft says:

    """<= /p>

    IANA is asked to create one new registry table.
    =

    2.1.=C2=A0 "SMI Security for Cryptographic Algorithms" Regist= ry

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

    """

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


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

    https://www.iana.org/ass= ignments/smi-numbers/smi-numbers.xhtml
    https://www.iana.org/assignments/smi-numbers/smi-numbers= .xhtml#smi-numbers-26

    Alt= hough I am not aware of a registration procedure for these tables and the c= urrent, I believe it would be useful to specify explicitly all fields assoc= iated to the table.

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

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

    =C2=A0=C2=A0=C2=A0 - Referen= ce: It seems to me that the current document would be appropriated.<= u>

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

    =C2=A0

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

    =C2=A0

    Experts are normally suggested by the au= thors, chairs or shepherds of the document during the IESG review process a= t the request of the AD.

    =C2=A0

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

    =C2=A0<= u>

    jim

    =C2=A0 <= /u>

    =C2=A0

    =C2=A0

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

    I hadn=E2=80=99t read it before, bu= t it does what it says it=E2=80=99s going to do and it=E2=80=99s pretty dar= n short and straight forward.=C2=A0 Ship it!

    spt


    > On Jun 2, 2017, at 16:39, Daniel Mi= gault <    = daniel.migault@ericsson.com> wrote:
    >
    > Hi,
    >
    &= gt; This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. = The draft received significant comments during the WG adoption and is expec= ted to be close to its final version. Please provide your feed backs by Jun= e 16.
    >
    > Yours,
    > Rich and Daniel
    >
    > [1] https://datatracker.ietf.org/doc/draft-schaad-curd= le-oid-registry/

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

    ____________________________________________= ___
    Curdle mailing list
    Curdle@ietf.org
    https://www.ietf.org/mailman/listinfo/c= urdle

    =C2=A0


    _________________________________________= ______
    Curdle mailing list
    Curdle@ietf.org
    https://www.ietf.org/mailman/listin= fo/curdle

    = =C2=A0

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

    =C2=A0


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

    =C2=A0


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

    =C2=A0

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

    --089e082756b8df0d18055a435513-- From nobody Thu Sep 28 11:18: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 4D86F1342F4 for ; Thu, 28 Sep 2017 11:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 I_dShyXp8U5l for ; Thu, 28 Sep 2017 11:18:39 -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 A7E151345FD for ; Thu, 28 Sep 2017 11:18:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01D3384B.77D55A50" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1506622671; h=from:subject:to:date:message-id; bh=kl57oVvPZ+lruWJiMd7JG6NfU3dzQBG+E79lLq5O5OM=; b=LHmDPvw4rchfeznQYLJJv96+V1kWLxqJovc2FRvI1F/RsQuIZkyspuxmXLv+QTBKSh/f3/xF9Pv +jAIQNq1n6kQJJ2VSsI5J/H6teH9IhgSp5O+GLLDC9+5I6wVffmEvv5huMH5a2AQjpQz6O/T5iNtr lZtdvm2H7uL2a7jLHK/BxBlTWmySewzPs0ap/knuwyPTQhwkWyJnV37RwwPc4TWAfNg23FxDw9ywF mHoK3XRwtThYz+mMzT6DnYsm0W6+FxHnZmPKcqFzz0FcLGo5M/COLXWQBUBwG80iKvjTTYiVLXV86 a6zWq+oBMXnzd/Tzx8zGADXl7fa27bcAOvHg== 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, 28 Sep 2017 11:17:49 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 11:17:24 -0700 From: Jim Schaad To: 'Daniel Migault' , 'Russ Housley' CC: 'curdle' , 'Sean Turner' References: <3895FA29-6856-4024-955F-D8C0CBADF42A@sn3rd.com> <03af01d2e09f$518e7c40$f4ab74c0$@augustcellars.com> In-Reply-To: Date: Thu, 28 Sep 2017 11:18:07 -0700 Message-ID: <001d01d33886$2430fe00$6c92fa00$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb1xZwqGaWy4iJzjCFcw91l4MwcAKUrU/kAn9JjwACxKIGkAHJEGYKAsAQmu4DfUDCtqE6Zjpg X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 18:18:41 -0000 ------=_NextPart_000_001E_01D3384B.77D55A50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looks fine to me. =20 From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault Sent: Wednesday, September 27, 2017 12:08 PM To: Russ Housley Cc: Jim Schaad ; curdle ; Sean = Turner Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Thanks. It is better to be explicit and complete.These have been = addressed. Yours,=20 Daniel =20 =20 On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley > wrote: Daniel Migault is the document shepherd and Eric Rescorla is the = responsible Area.=20 s/Area/Area Director/ =20 Some questions do not have answers: (8), (13), (15) =20 Russ =20 =20 On Sep 27, 2017, at 2:56 PM, Daniel Migault > wrote: =20 Hi,=20 Please find the shepherd write up: =20 https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepher= dwriteup/ =20 Feel free to comment, by the end of the week.=20 =20 Yours,=20 Daniel =20 Small comments: a) [I-D.ietf-curdle-pkix = ] should also be added as normative and=20 [I-D.ietf-curdle-pkix = -3] as informational. I think the normative comment is = missing Maybe a note to the editor should be added. We need to avoid the RFC = being in the informational reference ;-) b) the draft may be named ietf-curdle-oid-registry to reflect a WG = document c) title of section 2.1 may be removed and all its content placed in = section 2 d) If that is possible would it be possible to indicate the exact = location where the=20 table is expected to be added. Currently my understanding is that it is = not possible,=20 but once the table will be added you will be 1) more specific and 2) add = a link as an informal reference.=20 =20 On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad > wrote: =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Daniel Migault Sent: Thursday, June 8, 2017 12:55 PM To: Sean Turner > Cc: curdle > Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry =20 Hi,=20 Thank you for updating the draft Jim and Rick. While reviewing the draft = for the shepherd -write up I came with a few comments/questions. Please = find my comments below. Yours,=20 Daniel =20 COMMENT A)=20 The type of the draft is currently "informational". According to RFC = 2026 I am more incline to consider that BCP would be more appropriated. = Any thoughts on that ? The draft does not discuss any technical content. The draft describes = the set of OIDs that have been donated. In some ways, it also assigns = OIDs that have not been assigned by any other RFCs ( but only version-03 = of the pkix draft). It also describes the creation of an IANA registry = table, as well as update procedure for adding new entries which = includes, parameters to provide, the review process to follow and the = way the arc can be extended.=20 In that sense according to RFC2026 the document is essentially = documenting IETF operations and so BCP seems the appropriated type. [JLS] I am not sure how you would presume that this could be a BCP? = What practices are we recommending that be followed? I think that this = makes far more sense as informational. There is nothing that says that = an informational draft be technical. Lots of informational drafts are = about procedures or about thought processes. I would keep this where it = is. =20 COMMENT B)=20 It might my fault as I commented on the earlier version the references = [I-D.ietf-curdle-pkix = ] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks = confusing to have OIDs reserved for a specific Description while not = being assigned. As we have the intention to keep these OIDs, I think you = opened a better path to have a RFC as a reference than having an old = version of a draft.=20 I interpret the the following text as explaining why we ended up with = id-EdDSA25516-ph and id-EdDSA448-ph.=20 """ After those registrations were done, there were still some unused values that can be used for other security groups, there were still some unused values. """ Placing the current document as the Reference would clarify, in my = opinion, the status of these OIDs. It may be useful to add some text = that provides more explication with an reference to = [I-D.ietf-curdle-pkix = ]-03. As the RFC editor will probably replace = [I-D.ietf-curdle-pkix = ] with the RFC number, It might also be better to have = a specific informational reference. =20 [JLS] There is a request in the XML that the RFC editor make sure that = this specific reference point to the version of the ID and not the RFC. = However, it gets messy if you have [draft] and [draft-3] I the same = document as well. Visually, it is currently a hard thing to do. COMMENT C) The draft says: """ IANA is asked to create one new registry table. = 2.1. "SMI Security for Cryptographic Algorithms" Registry =20 Within the SMI-numbers registry, add an "SMI Security for Cryptographic Algorithms" table with the three columns: """ Maybe we should also specify that the SMI Security for Cryptographic = Algorithm registry is a sub-item of the "SMI Security Codes Registries". = I believe it would be useful to have an URL as an informational = reference for both the "SMI-numbers registry" as well as for "SMI = Security Codes Registries".=20 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-26 Although I am not aware of a registration procedure for these tables and = the current, I believe it would be useful to specify explicitly all = fields associated to the table.=20 - Registration: Procedure Although it can be inferred from the = current text. I believe it is helpful to the IANA to have the exact = filed value associated to all fields.=20 - Description: The description is usually the arc ID, maybe in our = case we should add the range of provided OIDs. - Reference: It seems to me that the current document would be = appropriated. - Expert: The Registration Procedure mentions Expert review. I am = not sure experts should be listed in the in the RFC RFC5226 appointed = by IESG. =20 =20 [JLS] This is really a bit of a mess, because it does not really belong = under the SMI Security Codes section if one were being string. It is = not prefixed with the OID defined for that section. It is unfortunate = that Russ had all of the PKIX and S/MIME registries placed below that = section. However using the registry template associated with that would = not really be correct. I may talk to IANA during the process of final = registration to see if we can create a new header and move all of the = registries into that new header but I don=E2=80=99t want to do that as = part of this document as it probably would be messy to state. This type = of decision is normally made on the fly during the registration process = and is not normally called out explicitly. =20 Experts are normally suggested by the authors, chairs or shepherds of = the document during the IESG review process at the request of the AD.=20 =20 We will end up with an entry that looks like = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-s= mime-3 which provides a template of what is defined here. =20 jim =20 =20 =20 On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner > wrote: I hadn=E2=80=99t read it before, but it does what it says it=E2=80=99s = going to do and it=E2=80=99s pretty darn short and straight forward. = Ship it! spt > On Jun 2, 2017, at 16:39, Daniel Migault > wrote: > > Hi, > > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The = draft received significant comments during the WG adoption and is = expected to be close to its final version. Please provide your feed = backs by June 16. > > Yours, > Rich and Daniel > > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ > _______________________________________________ > Curdle mailing list > Curdle@ietf.org =20 > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_001E_01D3384B.77D55A50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Looks fine = to me.

     

    From: = mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault
    Sent: Wednesday, September 27, 2017 12:08 = PM
    To: Russ Housley <housley@vigilsec.com>
    Cc: = Jim Schaad <ietf@augustcellars.com>; curdle = <curdle@ietf.org>; Sean Turner = <sean@sn3rd.com>
    Subject: Re: [Curdle] WGLC = draft-schaad-curdle-oid-registry

     

    Thanks. It is better to be explicit and complete.These = have been addressed.

    Yours, =

    Daniel

     

     

    On Wed, = Sep 27, 2017 at 3:01 PM, Russ Housley <housley@vigilsec.com> = wrote:

    Daniel Migault is =
the document shepherd and Eric Rescorla is the responsible Area. =

    s/Area/Area = Director/

     

    Some questions do not have answers: (8), (13), = (15)

     

    Russ

     

     

    On Sep 27, 2017, at 2:56 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:

     

    Hi, =

    Please find the shepherd write = up:

     

     

    Feel free to comment, by the end of the week. =

     

    Yours,

    Daniel

     

    Small = comments:

    a)

    [I-D.ietf-curdle-pkix] =
should also be added as normative and 
    [I-D.ietf-curdle-pkix-3] =
as informational. I think the normative comment is =
missing
    Maybe a note to the editor should be added. =
We need to avoid the RFC being in the informational reference =
;-)
    b) the draft may =
be named ietf-curdle-oid-registry to reflect a WG =
document
    c) title of =
section 2.1 may be removed and all its content placed in section =
2
    d) If that is =
possible would it be possible to indicate the exact location where the =

    table is expected to be added. Currently my understanding is that it =
is not possible, 
    but once the table will be added you will be 1) =
more specific and 2) add a link as an
     informal reference. =

     

    On Thu, = Jun 8, 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

     <= /o:p>

     <= /o:p>

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

     <= /o:p>

    Hi, =

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

    Yours, =

    Daniel<= /o:p>

     <= /o:p>

    COMMENT A) =

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

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

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

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

     <= /p>

    COMMENT B) =

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

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

    """

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


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

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

    COMMENT = C)

    The draft = says:

    """

    IANA is asked to =
create one new registry table.

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

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

    ""= "

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


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

    https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml
    https://www.iana.org/assignments/smi-numbers/smi-number= s.xhtml#smi-numbers-26

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

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

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

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

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

     <= /o:p>

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

     

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

     

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

     

    jim

      =

      =

     <= /o:p>

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

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

    spt


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

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

     <= /o:p>


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

     

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

     


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

     

    ------=_NextPart_000_001E_01D3384B.77D55A50--