IETF Logo Mail Archive

Re: [CFRG] Adoption Call: Guidelines for Writing Cryptography Specifications

Hubert Kario <hkario@redhat.com> Thu, 22 June 2023 12:58 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB240C135DFB for <cfrg@ietfa.amsl.com>; Thu, 22 Jun 2023 05:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AuXBlHQJ9oA for <cfrg@ietfa.amsl.com>; Thu, 22 Jun 2023 05:58:42 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2E2C13612C for <cfrg@ietf.org>; Thu, 22 Jun 2023 05:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687438702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HgDNxgF+iV9MFgB+2JXRfuw/NT9vXRoE1+/LbQy9VZw=; b=E6UCHiMs5iXi1jIwqVRwJ8vNDF5ucKAx7MiAcrUe54edOIqTdAgaxv0F+SF/NPmk7+nI0+ RIJOJ4W7neAyj4NQ8AHewF29+YyzT6ARZlGPJs+WmwZ6UNbE5gkNOW2OZ3a/yZYBxDtSiY rwftvbmaW/yDxDvAd+tcZSzEB3UVGgM=
Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-478-I9A-o6uIO7OWJNt5H-jT4g-1; Thu, 22 Jun 2023 08:58:21 -0400
X-MC-Unique: I9A-o6uIO7OWJNt5H-jT4g-1
Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-986db3313f0so411783966b.3 for <cfrg@ietf.org>; Thu, 22 Jun 2023 05:58:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687438700; x=1690030700; h=content-transfer-encoding:user-agent:organization:references :in-reply-to:message-id:mime-version:date:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Doh4mIsucRTfCNGQGyWkLxq/JC7bIg4gyfR0Kxy2sC0=; b=QYPPjx/sejpSdajYAxDh5GkL5qDrf93b9zW7i6lVfy/ViRscgMqrY+e0UU7mVMlYig AJUJBAAeMxvd5UTyhBzIRFwQMnPboz26lD032GL51kaPKRxodZXIYnyyRcUhHQCBLUbN XxQNp7UhdoDEr7bywiphYhIp+U/Jo7cKq2ImqjawbPYLCX+7hF3/TUVSiaX+awqdl0Ai Z6a77VLsuCsK4V1gzaaruqfTpq/mnV3XApQyIvIYYCbvt0x/cBC/KxRwBFaKjlbmWS7I G+UlMR5D15Ewr+7A9nczHk6amKERIlkAS4+T8GqECO9P+KepHkk+rmTZSMusQvx5UQLv TjLA==
X-Gm-Message-State: AC+VfDzpMAWTvBCLFcvGN01EieMNUtIsLFB7zpWfgrIWtZkhA20v0JoF LyfmmsHQg7rSRm++lFZoGTeURq5ah/9zRM57vf7nKxq+7vYfwFbUBeBQkYeHAYCinzaZhXyPgWA Ale98
X-Received: by 2002:a17:907:6e10:b0:988:8d88:1ba8 with SMTP id sd16-20020a1709076e1000b009888d881ba8mr10834841ejc.30.1687438700067; Thu, 22 Jun 2023 05:58:20 -0700 (PDT)
X-Google-Smtp-Source: ACHHUZ7EtQyXY//QIryX/ELBIrC8ukfJgNuD+rIjNpluvelzatsaX9zK4af3edocrwi/3yEM5ECCTQ==
X-Received: by 2002:a17:907:6e10:b0:988:8d88:1ba8 with SMTP id sd16-20020a1709076e1000b009888d881ba8mr10834831ejc.30.1687438699787; Thu, 22 Jun 2023 05:58:19 -0700 (PDT)
Received: from localhost (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id z17-20020a1709063ad100b009821ce1ea33sm4642639ejd.7.2023.06.22.05.58.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jun 2023 05:58:19 -0700 (PDT)
From: Hubert Kario <hkario@redhat.com>
To: Jonathan Hammell <jfhamme.cccs@gmail.com>
Cc: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, "<cfrg@ietf.org>" <cfrg@ietf.org>, cfrg-chairs@ietf.org, "Hammell, Jonathan F" <jonathan.hammell@cyber.gc.ca>
Date: Thu, 22 Jun 2023 14:58:18 +0200
MIME-Version: 1.0
Message-ID: <36126e45-f7d0-4411-9512-76fe4c71b3db@redhat.com>
In-Reply-To: <CALhKWgjBmjRWiXoUOwotfxc-Ls7nrpCoOGN1qoVNHcwm4N_VFg@mail.gmail.com>
References: <CAMr0u6=oLzn1SzzuO5X4aLw2neRf=bqMJpMOB4h3ERTO4Ao-WA@mail.gmail.com> <CALhKWgjBmjRWiXoUOwotfxc-Ls7nrpCoOGN1qoVNHcwm4N_VFg@mail.gmail.com>
Organization: Red Hat
User-Agent: Trojita/0.7-git; Qt/5.15.9; xcb; Linux; Fedora release 37 (Thirty Seven)
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/fwclKSg9_0AkCqY40LwaxoO_5Lw>
Subject: Re: [CFRG] Adoption Call: Guidelines for Writing Cryptography Specifications
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jun 2023 12:58:42 -0000

On Wednesday, 21 June 2023 20:13:25 CEST, Jonathan Hammell wrote:
> I think this draft will be useful and I support RG adoption.
>
> While there is a recommendation in Section 3.2 to specify data
> formats, encodings and serialization methods, I would like to see some
> guidance in Section 4 or 5 to explicitly recommend interfaces use
> implementation-friendly data formats (e.g. octet strings) rather than
> mathematical elements.

+1 to that, I'd also like to see that the pseudocode should explicitly
call out any operations that will not end up being side-channel secure
if implemented with a naïve approach (big number arithmetic, selection
between two values, etc.)

> Also, the authors might consider adding some specific guidance in
> Section 3 (maybe in 3.3.1.5) related to diagrams of message flows for
> specifications involving protocol messages (e.g. OPAQUE).
>
> Best regards,
> Jonathan
>
> --
> Canadian Centre for Cyber Security
>
> On Fri, Jun 2, 2023 at 1:15 AM Stanislav V. Smyshlyaev
> <smyshsv@gmail.com> wrote:
>> Dear CFRG participants,
>> 
>> This message is starting 3 weeks adoption call on "Guidelines 
>> for Writing Cryptography Specifications" draft, 
>> draft-sullivan-cryptography-specification-00 
>> (https://datatracker.ietf.org/doc/draft-sullivan-cryptography-specification/) 
>> that will end on June 23rd 2023.
>> 
>> Please send your feedback in reply to this email or directly 
>> to CFRG chairs <cfrg-chairs@ietf.org>.
>> 
>> Best regards,
>> Stanislav (for CFRG chairs) ...
>

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

v2.23.0 | Report a Bug | By Email