Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt
Daniel Migault <daniel.migault@ericsson.com> Thu, 06 July 2017 16:01 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D206131630; Thu, 6 Jul 2017 09:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLuypDPaTwGA; Thu, 6 Jul 2017 09:01:53 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0DB12EBFE; Thu, 6 Jul 2017 09:01:52 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id h22so6699089lfk.3; Thu, 06 Jul 2017 09:01:52 -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=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=EdqDeqT25FbhyM8KyTDDO8kVbfUIdR92hq4rMHtTWsiuoC9utHryGqQ6lVLzgqzx+0 j+XEC8672QPFnXt3yc/BSzaD/+lB5dHrrsIUjR3Btu6JEHtb13dZyOHSY3bvuGnsxCnH Qdnxcb1KyDIkHMl+hFSNsQfnts2CC0J0msOpj/b0Md3wIR+cL3ac/wgBVfRrgLJAgzNg s6FnCW3pi3yv/Iv9DxP8/15rK43fsRt4GyJd6qHNL76F92VuO+pZCRudb2wArWihEzRt T0LjAvUE/lWX6nyYC1DdwJ+Juk9ycse3/uIE/YQALyuvza69/yOIsF0vKq7Hr+tta8F/ 24/g==
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=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=NhdJfnWlJ/F8VZMi1TtAMMcEPywgswLpzyLLHQBF+uVWIobQTlG8F/euIF2MLL53wJ 6s+0VUQH/Gw7zV2neLnpc/mVbumj0Yad+DZO1oC+twCO/NGQ9NA//rHS2fepjTM1ZJjC 7gihXEZpAIAa+aP1vtvOFiz81mxijtWuuxv4z9WrALniDwxTHPLIWcc+6n415mL+MUUK QEtZ7OvwS3nY8P8jUiKnRYo4GAdjHucGILrhjUZaAS6YHZB3nx8p3U+fdtJGTxuBc6OV SwKAqTmWEysdABeFuUldlkyc38nOSbyWOyFq0g7LIwDj+GNa4p4CJItbwv5dkeWEFSUA sqow==
X-Gm-Message-State: AKS2vOw7sDzkmU6VCGdqDDwuSCMf0vZtQlGTr6OpWZ66G0kQyCpSJtHq V9fSz4WQwUq4Gu0m0Cx35T2qXJP+bg==
X-Received: by 10.46.22.5 with SMTP id w5mr14244174ljd.26.1499356910766; Thu, 06 Jul 2017 09:01:50 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.5.20 with HTTP; Thu, 6 Jul 2017 09:01:49 -0700 (PDT)
In-Reply-To: <20170626021135.GF17840@kduck.kaduk.org>
References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 06 Jul 2017 12:01:49 -0400
X-Google-Sender-Auth: E2b5Z0emWnIB45XGF_HeUQvh4SM
Message-ID: <CADZyTk=tdD=PWqayf=QUtYFcAnavMEY3L6JkcostRKiGxGe5HA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Martin Rex <mrex@sap.com>, jaltman@secure-endpoints.com, kitten@ietf.org, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="f403045fbada0ed3e90553a83c36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/FgVVNlVKMnu0T9PuA7asHa1Dx4c>
Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 16:01:55 -0000
Hi, Thank you for the discussion. It seems that overall the current draft has a reached consensus. Are we ready to move the draft forward or do we need any additional discussions ? If you think more discussion is needed please let us know as soon as possible. Unless concerns are raised, I am planning to set the shepherd write up early next week. Regards, Daniel On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: > Hi Martin, > > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > > Benjamin Kaduk wrote: > > > > > > It sounds like you are asking for the addition of some text along > > > the lines of: > > > > > > Software support is only a bare minimum requirement for deprecating > > > RC4 enctypes; there may be additional logistical considerations > > > involved such as provisioning AES keys for all principals and > > > updating software configuration to enable AES and disable deprecated > > > encryption types. > > > > > > Is that something you are asking for? > > > > Yes, thank your. This sounds good to me. I consider it even more > > helpful than the reference to particular versions of particular > > OpenSource Kerberos implementations, because this is a characteristic > > that is sort-of implied by how kerberos-enctypes keys are created > > (derived by string2key) and probably affect all implementations of > > Kerberos, yet it is non-obvious to consumers of the technology. > > Thank you for clarifying your comment into a request. > > > > > There is a substantial difference between cipher suites in TLS, where > > key length, strength and algorithm for the symmetric crypto is mostly > > irrelevant to the (PKI) credentials, and where using new TLS cipher > suites > > and deprecating old TLS cipher suites does not have a rekeying > requirement. > > To some extent this is inherent in Kerberos's use of symmetric crypto for > authentication, as opposed to TLS which uses asymmetric crypto for > authentication and switches to symmetric crypto for efficiency for > bulk data transfer. > > > (Jeffrey Altman wrote:) > % In my opinion, such text is inappropriate for an RFC. The deprecation > % of the encryption type is a protocol action. The RFC is not guidance > % for system administrators. Such guidance should come from the protocol > % implementations. > % > % As such I believe the addition of text similar to the above is > % unnecessary for publication. > > > > > I do believe that it is very appropriate to provide such kind of a > > guidance in an RFC, so that it this recommendation for deprecation > > becomes more comprehensible and the trade-offs clearer to mere consumers > > of the Kerberos technology, readers that aren't Kerberos protocol experts > > and senior Kerberos implementers. > > In general I tend to hew more to Jeffrey's track that protocol > specifications > should limit themseles to protocol-level work. I could see some grounds > for an exception here, though, in that the deployment difficulties are > inherent to any Kerberos deployment that follows best practice of not > storing > user passwords (only derived keys). > > Given Jeffrey's reasoning, I do not think my above "proposed text" > (to get clarification from Martin) should be used as-is; if we do want > to provide the clarification that Martin wants, I would want to rephrase > things somewhat. But, it still seems unclear where the WG consensus lies > on the question of including any guidance at all, here. Can others > please weigh in? > > > > When making admins sufficiently aware of predictable interop-problems, > > we may actually see more administrative deprecation of weak Kerberos > > enctypes than leaving them in the dark, and it helps reducing the amount > > of stumped users, helpdesks and admins. > > Admins are more likely to read software-provided documentation than > protocol specs; this argument seems speculative to me. > > -Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Jeffrey Altman
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Martin Rex
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Martin Rex
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Jeffrey Altman
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Michiko Short
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Martin Rex
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Greg Hudson
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Michael Jenkins
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Daniel Migault
- Re: [kitten] [Curdle] I-D Action: draft-ietf-curd… Benjamin Kaduk