Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)
Randy Presuhn <randy_presuhn@alumni.stanford.edu> Thu, 21 October 2021 21:12 UTC
Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0B3A0CD0 for <opsawg@ietfa.amsl.com>; Thu, 21 Oct 2021 14:12:17 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnr7rZl2H6qq for <opsawg@ietfa.amsl.com>; Thu, 21 Oct 2021 14:12:12 -0700 (PDT)
Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 3C7323A0C4C for <opsawg@ietf.org>; Thu, 21 Oct 2021 14:12:12 -0700 (PDT)
Received: by mail-pf1-f174.google.com with SMTP id 187so1755584pfc.10 for <opsawg@ietf.org>; Thu, 21 Oct 2021 14:12:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=/92F+/OsEiUAqoI6PnsgGJju/gbdij+6he5/QluRbPc=; b=k1XpmJQsxk+h/nyOi1y8hWN4f0D7t67RMu0+S9T0RokqJpaw91+KawkY4bBUZ7f74U qqi0lyln92PlVp4+giarAa90LWLCU5Ryp33ImdgiL85xISzIebZOmFpzcibdN+JXYS9K hvFYrPzBUO0iIgbZtdZkXqFFXoCfeUsQj0RTZt17LlOuiKTt0rBWFbSj+F0elXuktveb 3a0yIYM/qdo7grgtUM0EBtKn8MgH23IWgR8E+unyxLotdax3jJ3pa2FpyS7uYtLyfFPa xKYMqfQYGbZUn3obsZgfCVtetJyulp1D/PE0CnY8Ymj2DQvUwVDcFuXHoJJGlMGaisB1 k0pA==
X-Gm-Message-State: AOAM530Ns9NSP+75Dui3VNzkAe5cNYMsxtoECv5/Ul0BWdstYQcvqBEw tuzgf+NOEbthpQ8wJIBFeGUX159cxHvwlA==
X-Google-Smtp-Source: ABdhPJxog4OOxk0YpcrfE18nW2oXYa0g8t2L0X9ExtlvKJwq/8oSTYroqmq97P/poUMjJNIPPHwKIw==
X-Received: by 2002:a63:970a:: with SMTP id n10mr6067617pge.427.1634850731672; Thu, 21 Oct 2021 14:12:11 -0700 (PDT)
Received: from ?IPV6:2601:646:9300:112b:a0c0:5c8a:d01d:2d87? ([2601:646:9300:112b:a0c0:5c8a:d01d:2d87]) by smtp.gmail.com with ESMTPSA id d12sm5920617pgf.19.2021.10.21.14.12.11 for <opsawg@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Oct 2021 14:12:11 -0700 (PDT)
Message-ID: <7f10d97a-3ba4-86b2-f484-c464a2ea6558@alumni.stanford.edu>
Date: Thu, 21 Oct 2021 14:12:09 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Content-Language: en-US
To: opsawg@ietf.org
References: <344570CB-D536-4FE5-82B9-32E8F8B63277@trevilon.com> <15342ee1-33f2-5930-49aa-4a6725718154@alumni.stanford.edu> <DCBB6926-5A18-4703-9D81-30190B8FB985@trevilon.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
In-Reply-To: <DCBB6926-5A18-4703-9D81-30190B8FB985@trevilon.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/MxPCt8UF9gSsVUkHgyrHHiO1DI0>
Subject: Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2021 21:12:21 -0000
Hi - On 2021-10-21 1:28 PM, Kenneth Vaughn wrote: ... > If I properly understand your suggestion, you are requesting that we > make the new document a stand-alone document and the group could > separately consider the retirement of RFC 6353 - perhaps on a separate > timeline. ... That seems sensible to me. It might have the advantage of being (potentially) less confusing during phased deployments, and I can imagine situations in which management infrastructure might need to support both - those transitions always seem to take longer than anyone would like. > The other key question (which might impact the answer to the first) is > whether the change to the MIB is necessary or if we can convince IANA to > maintain the one-octet hash algorithm identifier such that we can have > confidence that there will always be a unique number that we can use. > That would solve most of our problems (but perhaps add to the workload > of IANA) as I think any changes to the MIB would become trivial. As a > result, the update document would become very short. As I understand it, RFC 5246 already established an IANA-maintained registry in section 12, saying: TLS HashAlgorithm Registry: The registry has been initially populated with the values described in Section 7.4.1.4.1. Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action [RFC2434]. Values in the range 64-223 (decimal) inclusive are assigned via Specification Required [RFC2434]. Values from 224-255 (decimal) inclusive are reserved for Private Use [RFC2434]. The registry seems to still observe those constraints: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 I *think* that provides exactly what you're asking for. If the assignment hasn't already been made, your document could be, depending on what the WG thinks of it, the Standards Action or "required Specification" needed to make it happen through its own IANA considerations section. It sounds to me like it might be possible to just spell out the new elements of (protocol) procedure, the two(?) OBJECT IDENTIFIERS for these transport domains, the IANA considerations, and you'd be pretty much done. But TLS in all its subtle glory isn't my thing; if you haven't already done so, reach out to Wes Hardaker. Randy
- [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Upda… Kenneth Vaughn
- Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM … Randy Presuhn
- Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM … Kenneth Vaughn
- Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM … Randy Presuhn