IETF Logo Mail Archive

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

Eric Rescorla <ekr@rtfm.com> Mon, 19 August 2019 17:10 UTC

Return-Path: <ekr@rtfm.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 7B16212084B for <tls@ietfa.amsl.com>; Mon, 19 Aug 2019 10:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq-pufuoRI0q for <tls@ietfa.amsl.com>; Mon, 19 Aug 2019 10:10:50 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 2C28B12083B for <tls@ietf.org>; Mon, 19 Aug 2019 10:10:50 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id a30so1939538lfk.12 for <tls@ietf.org>; Mon, 19 Aug 2019 10:10:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eZLeAdarvu27rVs1XICgLKQVaVfw/8HFI/FKUMoh3XQ=; b=Rptymy4TQzgiSdxYBitwM8Cso1246xCk5S5gdUWmaIg1m6gbqCoh7zMZlLbqvhXCJj RUHgpAY3kPJcefDwcJuJJfxZfP++LN8675mcV7+i++lJfX4HZHycg0uS0GeAdOsxXm/Z ANAhHuGJmJtkuEG5Q49f9YtDeU97rmkTBHMxp4PUHdHgL8Cf3X2qT46R8s+NeBy+TbSP kp/HO54Su8Gv3joau2tz1+uFlbvGJU/IFurKaW/lC0LJWuVUjtyJcDqJOOL93TtesSll JGkh91sPHHCUhiM7GW5jadLjrYb0l5HqeRcHtJSjr/Cp+JiGwGnb0zMOXaHajDZph9fd QYfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eZLeAdarvu27rVs1XICgLKQVaVfw/8HFI/FKUMoh3XQ=; b=TD5EDPsAGU2YWegE66N/urPo8RiloP+UJgpvZmJZjLsq3lKE3Z8zlVmfEnSjaEaQbs 0eYdoSFa/oFsZoQjpvVipoaFt90PusLZc4YbNlh3YF6uHUluWt7iebte8SYS2mPaGjp+ OPDm6XCEI2PxO8k+Lj9IIlTZBSp5Z0ovXerI3zwwIeIxYSlBa7LSyBjncvEzfSPb2MWn IOM9nhlT+p35zICfuSUc5JY79b/ejuHrSVJaZMFfysonovdRQDN1YW45Ng7kWmCUSulg 21EczfpBcI5fafujSRnp87MH7f3qeUv7XsdvlJCKmRdwv7bjLCHxMR1pTo6x2CIqSPoM 48Gw==
X-Gm-Message-State: APjAAAXbp/QvSVn8JF/eUjZtOJnV4dnqNmKLQSvYtksrpnldiO9ySczQ PA5OMFxnwT+jQ8tMV4BDlKkO85rEbPcwpyomluUPaw==
X-Google-Smtp-Source: APXvYqx9PihmfGJwirxg36+/eGbS+bGMgv4KoIiZsk5RXRdrpZDqmjPu2Hq4LnEfbw7s6Qf7LRls1IFDOt69uqa6BQs=
X-Received: by 2002:a19:7908:: with SMTP id u8mr12773184lfc.178.1566234648341; Mon, 19 Aug 2019 10:10:48 -0700 (PDT)
MIME-Version: 1.0
References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <A644F3EC-B835-4D3C-A1FB-5D33547F1C84@akamai.com> <bf37b1f3-0fba-41a9-88a2-e5f50d95f56b.kepeng.lkp@alibaba-inc.com> <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> <CABcZeBOG0-BFU5-Zh4hSXOcV35ZYFPm21gzcpGAb0-J-ikJQUA@mail.gmail.com> <57CCBFBA-328E-470E-B3FA-B1088ED2971F@alipay.com>
In-Reply-To: <57CCBFBA-328E-470E-B3FA-B1088ED2971F@alipay.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Aug 2019 10:10:12 -0700
Message-ID: <CABcZeBON=Uni6mv5_QQ+e4Pt_ieZrP9fVa2WyZjWUpiSurMQbQ@mail.gmail.com>
To: Paul Yang <kaishen.yy@alipay.com>
Cc: Rich Salz <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d9860905907b6b52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HXKKUkxQX4DoXjfspK2fSL0Nz4M>
Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 19 Aug 2019 17:10:53 -0000

On Mon, Aug 19, 2019 at 7:32 AM Paul Yang <kaishen.yy@alipay.com> wrote:

>
>
> On Aug 18, 2019, at 9:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The intent of the "Specification Required" requirement for registration is
> that sufficient public information be available to allow an interoperable
> implementation. Specifically, the text says:
>
> https://tools.ietf.org/html/rfc8126#section-4.6
>
>    For the Specification Required policy, review and approval by a
>    designated expert (see Section 5) is required, and the values and
>    their meanings must be documented in a permanent and readily
>    available public specification, in sufficient detail so that
>    interoperability between independent implementations is possible.
>    This policy is the same as Expert Review, with the additional
>    requirement of a formal public specification.  In addition to the
>    normal review of such a request, the designated expert will review
>    the public specification and evaluate whether it is sufficiently
>    stable and permanent, and sufficiently clear and technically sound to
>    allow interoperable implementations.
>
> I don't think that a for-pay specification meets that threshold, though I'm
> not aware of any IETF-wide policy on that (although I may just have missed
> it).
>
>
> Makes sense, so we added new public documents now ;-)
>
> Just one question, do implementations count as the ‘public specification’?
> For instance, something like the crypto libraries which support the
> algorithms with full documentation describing it...
>

I do not think so, no.

-Ekr


>
> In the absence of that, it would as stated above, be on the Expert to
> determine
> the standard.
>
> -Ekr
>
>
>
>
>
> On Sun, Aug 18, 2019 at 2:52 PM Salz, Rich <rsalz@akamai.com> wrote:
>
>>
>>
>> Ø  This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt
>>
>>
>>
>> Thank you.
>>
>>
>>
>> That is a bit different since RNC isn’t needed to implement the RFC, and a web search for “relaxng” finds thousands of references.  The SM2, etc., situation is different because you cannot implement the cipher without the definition of it.
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> Regards,
>
> Paul Yang
>
>

v2.23.0 | Report a Bug | By Email