Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt

From: Robert Moskowitz <[email-masked]>
Date: Sun, 15 Sep 2019 19:19:52 -0400

This completes the first set of drafts for tm-rid.

This draft has a couple drafty areas.  Particularly in the cipher, I 
need to study Keyak more, but this is what I was advised to use.

The Keymat is really a new approach, but pulled directly from NIST 
sp800-56Cr1.

There are a number of other new ways of doing things, leveraging Keccak.

So take a read.  I am attending the UAS symposium: 
https://nuair.org/symposium/

the next couple days along with Stu and Adam.  I expect to have 
additional information from this gathering.

I will be working on the DNS storage of HHITs for updates, plus other items.

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-hip-new-crypto-00.txt
Date: 	Sun, 15 Sep 2019 16:12:21 -0700
From: 	[email-masked]
To: 	Stuart Card <[email-masked]>, Adam Wiethuechter 
<[email-masked]>, Robert Moskowitz 
<[email-masked]>, Stuart W. Card <[email-masked]>

A new version of I-D, draft-moskowitz-hip-new-crypto-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 00
Title: New Cryptographic Algorithms for HIP
Document date: 2019-09-15
Group: Individual Submission
Pages: 11
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 18 Sep 2019 14:12:59 -0400

Bob,

I have reviewed this finally. I am not crypto expert so a lot goes over my
head and I have to run down rabbit holes to attempt to understand it but I
think I have a broad enough picture now. My comments are in rough order
here.

I like that you call out that this is targeting "constrained devices and
communication" in the introduction - good call. HIP probably needs a bit of
an update overall in keying/hashing (I know Stu would love to have
SECP256K1 as an option at some point) but that is out of scope here in this
draft.

In Section 2.2 I see that Keccak and KMAC have the same content in
parenthesis. Is this intentional?

In Section 3 you make the following comment: "The specification of the HIP
parameters and their mapping to HIP packets and packet types is flexible to
allow HIP extensions to define new parameters and new protocol behavior." I
am wondering if a possible goal is to create a sort of "Constrained
Environment Extension (CE_EXT)" to HIP that adds other fundamental changes
to how HIP behaves (as well as pull in other extension such as the DEX) on
top of these crypto changes. Just food for thought.

I noticed in Section 3.2.2 that you have given EdDSA/SHAKE128 a index of
"5". I reviewed RFC7401 to find that the index goes up to "3". I checked
DEX draft and a few others. What is index 4? I am assuming its in another
document that is an addendum to 7401 but I can't find it. Just a nitpick as
having everything in one place makes life easier for implementations to not
miss something. Same thing goes for Section 3.1.1 and 3.4.1.

Section 3.2.1: you reference HOST_ID parameter but point to RFC7041 Section
5.2.19 which is Notification? I think you meant RFC7401 Section 5.2.9.

Section 3.3.1, I see that in paragraph 3 you break down into bytes for each
r-value. Perhaps do something similar to the paragraph before to be
consistent and helpful for those dealing with bytes and not have to do a
conversion.

Section 4: Add the word "to" in the first sentence - it doesn't flow right
("vary slightly TO the ORCHID generation"). And just clarify; the XOF of
cSHAKE removes the need for Encode_96 as cSHAKE will produce a 96 bit
value? I need to re-read for the EdDSA again, I feel like I am missing
something here in my though process of how HIT generation works.

Looks good so far to me. I will read up more on cSHAKE and the other crypto
things to hopefully give more insightful comments next time.

On Sun, Sep 15, 2019 at 7:20 PM Robert Moskowitz <[email-masked]>
wrote:

> This draft has a couple drafty areas.  Particularly in the cipher, I need
> to study Keyak more, but this is what I was advised to use.
>
> the next couple days along with Stu and Adam.  I expect to have additional
> information from this gathering.
>
> To: Stuart Card <[email-masked]> <[email-masked]>,
> Adam Wiethuechter <[email-masked]>
> <[email-masked]> <[email-masked]>, Stuart W. Card
> <[email-masked]> <[email-masked]>
>
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter