IronPort-Data: A9a23:kEunnaP+ZBwzDdbvrR3JlsFynXyQoLVcMsEvi/4bfWQNrUp2hjcFm
 GQXXGvVb/aCZWPyLosiO4yypBwD6MXWzd43GQZtpSBmQkwRpJueD7x1DKtS0wC6dZSfER09v
 63yTvGacajYm1eF/k/F3oDJ9CQ6iOfRAOKhVYYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE0
 T/Ii5S31GSNhXgsYwr414rZ8Ekz5KSq6WtC1rADTasjUGH2xiF94K03ePnZw0vQGuF8AuO8T
 uDf+7C1lkux1wstEN6sjoHgeUQMRLPIVSDW4paBc/H/6vTqjnVaPpcTbJLwW28O49m6t4kZJ
 OF2iHCFYVxB0pvkw71BDkYCQ0mSCoUdkFPPCSDXXcW7kRWaIyO0qxlkJBle0YYwoo6bDYzSn
 BCxxf9kgh2r3oqLLLyHpuZEgPsPM861F4cjoF5p1mDkD9d3X7H5evCfjTNY9G9YasFmPNLxP
 vU/RAo3NlLeaBpVIhEeBNQghvyuwHL4dlW0qnrM/extvzaVlVErluKzWDbWUoXiqcF9lEWRo
 mPd/GXRHBwANceexjzD+XWp7gPKtXimBNpMTuXinhJsqEPN6kIoVjM/bmTlhPyEpky0cu5NE
 nVBr0LCqoB3riRHVOLVVBOir1aFpAISHd1KHIUHBBqly67buhmfC3hcFHtadsZgsc4tADYtk
 F6NkIqvGyZ0tvueTnf1GqqokA5e8BM9dQcqDRLohyNcizU/iOnfVi7yc+s=
IronPort-HdrOrdr: A9a23:Won6J69M1AP+0hCUTKpuk+AFI+orL9Y04lQ7vn2ZLiYlF/Bw9v
 re/sjzuiWVtN98Yh8dcLO7V5VoKEm0naKdirNhXotKMjOGhEKYaK9v6of4yyDtFmnU5odmuZ
 tIQuxbBMfrBVZ3yeT38GCDeeoI8Z2i/LqzjenTi01xSxpnApsM0y5iBh2FHlZNSA5KOJo8GP
 OnjfZ6mw==
From: "Kaliski, Burt" <bkaliski@verisign.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Request for adoption:  Signature modes guidance /
 draft-harvey-cfrg-mtl-mode-03
Thread-Index: AdrnPT76cphfzukXQ+q85fcbW10/RQDJLKQg
Date: Fri, 9 Aug 2024 15:21:36 +0000
Message-ID: <1303edf5a027444ca135ba36a579e186@verisign.com>
References: <43f8434f68c144f38b4a4a3933841899@verisign.com>
In-Reply-To: <43f8434f68c144f38b4a4a3933841899@verisign.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: MNLBJKBIKNDN344553PLQ6YXL6MLOGBO
Precedence: list
Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Request_for_adoption=3A__Signature_modes_guidance?=
 =?utf-8?q?_/_draft-harvey-cfrg-mtl-mode-03?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/cfrg/KM_qiaK3VN-BZ5OPkm1cZQkg_bI>

Thanks all for the thoughtful feedback to my request.

I've included responses to the technical comments below.

Note that although draft-harvey-cfrg-mtl-mode-03 is the document under disc=
ussion, the proposal I'm making is broader. I am asking that CFRG provide g=
uidance to protocol designers on signature modes of operation more generall=
y.  In particular, how to combine hash functions and other techniques with =
an underlying signature algorithm to obtain additional security and operati=
onal properties.

> [Watson Ladd] I don't understand why this is in the CFRG: it seems to be =
squarely in the line of decisions WGs have made outside CFRG such as keytra=
ns or CT.

WGs have made decisions on using pre-hashing and Merkle tree constructions =
in various ways, and they could continue to do so for MTL mode and other te=
chniques. However, while WGs may have built on one another's experiences in=
 deciding on their cryptographic constructions, the specifications of these=
 constructions have generally been made within the applications themselves.

Having common specifications for these kinds of constructions would be help=
ful not only for interoperability but also for addressing security question=
s such as:

(a) which hash functions to use in combination with particular signature al=
gorithms (discussions along these lines are underway in LAMPS for composite=
 signatures);=20
(b) how to handle the case that an application uses the same key pair in tw=
o different modes (e.g. "pure" and "pre-hashing" -- should there be a "doma=
in separator");
(c) whether and when to include other inputs to the hash functions (randomi=
zer, public key, etc.) to achieve additional security properties;
(d) how to model interactions between the use of hash and other functions i=
n the construction, and in the underlying signature algorithms, as they may=
affect security proofs.

Questions like these are more squarely in the line of CFRG than in the WGs =
integrating the constructions into their applications.

> [Watson Ladd] Separately while I think the idea is interesting, there's a=
 lot of operational and structural questions to actually apply it very clos=
ely ingrained with application and protocol level considerations. CFRG isn'=
t really suited to determine if this will work. This is not to say it shoul=
dn't be pursued, but I just have a lot of questions about how it would work=
 fro DNSSEC for instance.

Agreed. We expect that specifications for integrating MTL mode into a given=
 application, e.g., DNSSEC (see draft-fregly-dnsop-slh-dsa-mtl-dnssec-02) w=
ill give further detail specific to the application. The focus for CFRG wou=
ld be the cryptographic constructions.

> [Richard Barnes] I tend to agree with Watson here. It's not clear to me w=
hy this is a new signing mode vs. just another data structure that gets sig=
ned.  Plenty of other signed hash-based data structures have been defined b=
y Certificate Transparency, the various flavors of Key Transparency, and ot=
hers. As Watson says, and as these examples illustrate, the details of thes=
e data structures tend to be pretty application-specific. So it seems like =
this work might be better done in a venue with more DNSSEC expertise, even =
if it might be reusable elsewhere.

As noted, the focus for CFRG would be on the cryptographic constructions. T=
hese reusable parts would benefit from CFRG expertise on the state of the a=
rt in cryptographic design. For example, draft-harvey-cfrg-mtl-mode-03 adop=
ts techniques from SPHINCS+ to reduce the size of the internal hash values =
and to move to security properties such as multi-function, multi-target sec=
ond-preimage resistance. These kinds of changes are much more within CFRG e=
xpertise than DNSSEC.

> [Mike Ounsworth] But CT doesn't externalize data needed to validate the s=
ignature into the CT data. I think that's what makes it a "signature mode" =
rather than a "protocol".

> I also think that the authors are trying to get cryptographic review of t=
he crypto and show that this mode could be used beyond DNSSEC, hence bringi=
ng it to CFRG.

Yes, in MTL mode, signatures can be distributed in two parts, a short "cond=
ensed signature" for a specific message, and a longer "signed ladder" that =
can authenticate multiple messages. The two parts of the signature for a gi=
ven message can also vary over time as additional messages are signed. We s=
ee this approach as a signature mode because the parts are cryptographic co=
nstructions and agree that it could be used beyond DNSSEC.

-- Burt

(Note:  Reference [10] in my initial email refers to draft-ietf-lamps-pq-co=
mposite-kem-04.  It should have referred to draft-ietf-lamps-pq-composite-s=
igs-02.)


-----Original Message-----
From: Kaliski, Burt
Sent: Monday, August 5, 2024 9:43 AM
To: 'cfrg@irtf.org' <cfrg@irtf.org>
Cc: Fregly, Andrew <afregly@verisign.com>; Harvey, Joseph
<jsharvey@verisign.com>; Sheth, Swapneel <ssheth@verisign.com>
Subject: Request for adoption: Signature modes guidance /
draft-harvey-cfrg-mtl-mode-03

CFRG,

Following up on my presentation at IETF 120, I would like to request that
CFRG adopt draft-harvey-cfrg-mtl-mode-03 [1] as part of a broader research
effort to provide guidance on modes of operation for digital signature
schemes in applications.  The authors' rationale is as follows:

* NIST is in the process of standardizing what are effectively two modes of
operation for FIPS 204 and 205 - "pure signing" where the message is signed
directly with the underlying signature scheme and "pre-hash signing" where
the hash of the message is signed.  NIST has also introduced a "domain
separator" format to distinguish the two modes [2].
(draft-harvey-cfrg-mtl-mode-03 adopts the domain separator format to
distinguish MTL mode from others.)

* There are discussions underway on these topics on NIST's pqc-forum mailin=
g
list [3].  It seems prudent that CFRG advance guidance to applications on
how and when to use pure signing vs. pre-hash signing, how to use domain
separators and context strings in inputs to signature schemes, and how to
approach other modes of operation.

* The initial use case for MTL mode is DNSSEC, as described in
draft-fregly-dnsop-slh-dsa-mtl-dnssec-02 [4].  The current draft includes a=
n
example zone file signed with SPHINCS+ (SLH-DSA) in MTL mode.  The authors
hosted a hackathon session [5] on the draft at IETF 120 and also presented
[6] at HotRFC.  In addition, following the PQ DNSSEC side meeting [7], a ne=
w
non-WG mailing list, pq-dnssec [8], was formed in the Security Area.  The
mailing list will be used for discussions of
draft-fregly-research-agenda-for-pqc-dnssec-01 [9].  MTL mode is one of
several approaches for reducing the operational impact of post-quantum
signatures identified in the draft.

* Another example of a signature mode where CFRG guidance would be helpful
is composite signatures [10].  For instance, if the composite signature
construction is applied to FIPS 204/205, does this mean that FIPS 204/205 i=
s
operated in "pure" mode (because the pre-hashing has already been done)?
And how should an application use the optional context string provided by
FIPS 204/205 in a composite construction?

* Verisign announced a public, royalty-free license to certain intellectual
property related to draft-harvey-cfrg-mtl-mode-03.  IPR declarations
6174-6176 [11] give the official language.

Thanks -- Burt

[1] J. Harvey, B. Kaliski, A. Fregly, S. Sheth.  Merkle Tree Ladder (MTL)
Mode Signatures.  draft-harvey-cfrg-mtl-mode-03, June 12, 2024,
https://datatracker.ietf.org/doc/draft-harvey-cfrg-mtl-mode/03/
[2] D. Moody. Updates on pre-hash for FIPS 204 and 205.
pqc-forum@list.nist.gov mailing list, April 19, 2024,
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/JKMh0D0pa30/m/vbflX=
o
lxAQAJ.
[3] pqc-forum mailing list,
https://groups.google.com/a/list.nist.gov/g/pqc-forum
[4] A.M. Fregly, B. Kaliski. J. Harvey, D. Wessels.  Stateless Hash-Based
Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC.
draft-fregly-dnsop-slh-dsa-mtl-dnssec-02, July 8, 2024,
https://datatracker.ietf.org/doc/draft-fregly-dnsop-slh-dsa-mtl-dnssec/02/
[5] Exploring Implementation Approaches for Merkle Tree Ladder Mode
Signatures for DNSSEC, IETF 120 Hackathon,
https://wiki.ietf.org/en/meeting/120/hackathon
[6] A. Fregly, Stateless Hash-Based Signatures in Merkle Tree Ladder Mode
(SLH-DSA-MTL) for DNSSEC, IETF 120 HotRFC,
https://datatracker.ietf.org/meeting/120/materials/slides-120-hotrfc-sessa-=
0
4-stateless-hash-based-signatures-in-merkle-tree-ladder-mode-01
[7] Side Meetings at IETF 120,
https://wiki.ietf.org/en/meeting/120/sidemeetings
[8] pq-dnssec mailing list,
https://mailarchive.ietf.org/arch/browse/pq-dnssec/
[9] A.M. Fregly et al., Research Agenda for a Post-Quantum DNSSEC.
draft-fregly-research-agenda-for-pqc-dnssec-01, June 26, 2024,
https://datatracker.ietf.org/doc/draft-fregly-research-agenda-for-pqc-dnsse=
c
/01/
[10] M. Ounsworth et al., Composite ML-KEM for Use in the Internet X.509
Public Key Infrastructure and CMS.  draft-ietf-lamps-pq-composite-kem-04,
July 8, 2024,
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/04/
[11]
https://datatracker.ietf.org/ipr/search/?draft=3Ddraft-harvey-cfrg-mtl-mode=
&rf
c=3D&doctitle=3D&group=3D&holder=3DVeriSign%2C+Inc.&iprtitle=3D&patent=3D&s=
ubmit=3Ddraft