Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

Martin Thomson <martin.thomson@gmail.com> Tue, 21 November 2017 23:39 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A54129572 for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 15:39:43 -0800 (PST)
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 If6gOrAKe64y for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 9CE2D12947B for <tls@ietf.org>; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id d93so2066043oic.4 for <tls@ietf.org>; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
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=RQocx1CSZ1d4vEAvuK+1poBaa4DL2ur7XUxQ71N12Us=; b=YQBsDilw/oJweqjojPIAEEJyqY/ViaombZJQIASlGJraxKi20+QYJDameCM6mcpfYy Hwmam1IwLT4VQXE9yQFx2lA+nJMKUPRFp2kT1FulIH+lATPVzLHEvTZ27XfPHN1mZEA1 NlXQH+Xw3sqpDUSXsfWXVXhrlHFt6r5UsbptX9jGONQb6D6s9+VFA0X+A/Q8H62tSnaR ouAidu09yoqU7Ba4TU8j+S6r1wKlvtFfwhJ5tWnuubGd73ah4wbYGyEVSSAA94xSAccT IE9W9JRNhNXTOS7Lc+ZgivEhYjCm6OUYm3isDg6lfN8yIz8rt6KVbrMogCkIfPKp4Ija Dylg==
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=RQocx1CSZ1d4vEAvuK+1poBaa4DL2ur7XUxQ71N12Us=; b=jOUA5VRe+IrEASvJvPb9j64CnAGJH2I1i/8Gbg2eFvAUdeSeSFeLDlWxTMWdZqZFc8 9/7epSEtvYfQ3kHFcB4LSikQxLKH9tGquEEpeU9SIIeMxuwjFo+umuzAQCDoSlaegR59 ALiD7lVAaY25n8z5PkkKHDcEeiC+lIsa207Hc7aa3Uksh+ci0xNe/nDi6dNwUzqAE1V+ rkxsn0L/k2IMbph/dATWH4NQ4KKrHaBY8NC1VNejRDmc2lQT0JgW19EYD90C78IDMjDG /HpWS73szCC54uNBVzeo/s0PseYcpVr8bobdBMxvG42Af2Giaf/BzB2Csv+UnMwlxAAB jKog==
X-Gm-Message-State: AJaThX7PrCE5flRq6OTLx7eIQ3/gGy5cCAPVJI6GiK8zFW1IWCcq5wJd f65NfPv20MK8A5+ANZd9RUl0UoqlrvFaLm4mHy0E7Q==
X-Google-Smtp-Source: AGs4zMYJAdcJ3Jzaa0f1TXLlvhlh3qmPdn0BGYrxlkannhx6hTSfxE3bmpQYHj4KVJMzNoU2Yxnf43z+7tBCyNzzpgw=
X-Received: by 10.202.48.8 with SMTP id w8mr10867840oiw.284.1511307580581; Tue, 21 Nov 2017 15:39:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Tue, 21 Nov 2017 15:39:40 -0800 (PST)
In-Reply-To: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 22 Nov 2017 10:39:40 +1100
Message-ID: <CABkgnnVGVJN4PDQnDC5LbOnvsnv+DPecE4RQrvTvyVoK8aQDhw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ll368gV6Bwp0dPHyXKF_9nnyO_Q>
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 23:39:43 -0000

IESG action seems appropriate for both.  If we could include guidance
around this (values with Yes should only include those for which the
community currently has consensus are worth having available at the
current time), tat would be awesome.

On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> I just posted a draft shepherd write-up for this [1]. (The
> write-up text was mostly written by Sean as it happens - for
> which he has my thanks as it's boring as hell to do that:-)
>
> There are nits but only one substantive question that I don't
> recall the WG discussing before (but maybe I'm forgetting).
>
> What is needed to change from Recommended == Yes down to
> Recommended == No? Does that need a standards action (e.g.
> with an RFC) or just IETF review or even maybe just IESG
> action?
>
> In the current draft write-up I've put in the first as a
> placeholder, as that's symmetric with the No->Yes change but
> I think IESG action is probably ok if the WG wanted that as
> the IESG probably won't go crazy and will likely do as the
> WG want in such cases. If the WG do want to write a specific
> foo-no-longer-recommended RFC it can do that in all cases,
> and of course Yes->No transitions could be documented in an
> RFC that documents a "replacement" Yes entry.
>
> So, unless this was already discussed....answers on a postcard
> please - which'd we like:
>
> (1) say nothing (as in -02 draft)
> (2) say standards action is required for a Yes->No transition
> (3) say IETF review (i.e. an IETF last call) is required for a
>     Yes->No transition
> (4) say IESG action is required for a Yes->No transition
> (5) something else
>
> And as a reminder the Recommended column is not about crypto
> quality but is about things for which we have consensus that
> they ought be widely implemented and available at the current
> point in time. Those are related things but Recommended == No
> does not imply crap-crypto even if crap-crypto will hopefully
> imply Recommended == No.
>
> If nobody says anything I'll chat with Kathleen, Sean and Joe
> and we'll pick a thing and that'll doubtless be quibbled about
> during directorate reviews and IESG processing as these things
> always are;-)
>
> But since I'd hope implementers will care about keeping up to
> date with the set of Recommended == Yes things, I do hope that
> folks are willing to express a preference here.
>
> Cheers,
> S.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>