Re: [Dance] DANCE use for DRIP Network Remote ID

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 29 June 2022 23:26 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C345C14F746; Wed, 29 Jun 2022 16:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 6s-GWNFTtt2W; Wed, 29 Jun 2022 16:26:19 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (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 14871C14792A; Wed, 29 Jun 2022 16:26:16 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.152]) by relay.sandelman.ca (Postfix) with ESMTPS id 606611F40F; Wed, 29 Jun 2022 23:26:13 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 909231A01CB; Wed, 29 Jun 2022 19:26:03 -0400 (EDT)
Received: from dooku (localhost [127.0.0.1]) by dooku.sandelman.ca (Postfix) with ESMTP id 8F2D31A00B7; Wed, 29 Jun 2022 19:26:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
cc: dance@ietf.org, tm-rid@ietf.org
In-reply-to: <43933f77-6abf-7750-f5e9-e3d0e20135d5@htt-consult.com>
References: <43933f77-6abf-7750-f5e9-e3d0e20135d5@htt-consult.com>
Comments: In-reply-to Robert Moskowitz <rgm-sec@htt-consult.com> message dated "Fri, 24 Jun 2022 10:27:22 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 29 Jun 2022 19:26:03 -0400
Message-ID: <43229.1656545163@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/2diBtdkmyKkKHPYpySt7rXo5S7k>
Subject: Re: [Dance] DANCE use for DRIP Network Remote ID
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2022 23:26:24 -0000

Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
    > Please review:

    > Sec 3.2.1.2 in draft-moskowitz-drip-secure-nrid-c2

    > for DANCE (and DANE) usage.  Any improvement in this section is really
    > appreciated.

hi, the Introduction is really really rough.  It's all over the place, going
into solutions, non-solutions, etc.  This matters because its supposed to be
setting the scene for the rest of the document.

3.2.1.2 is one paragraph, one sentence in ..nrid-c2-10.txt.
}   HIP [RFC7401] for ESP Secure Link is a natural choice for a DET RID.
}   For this, the Net-RID SP would also need a HHIT, possibly following
}   the process in [drip-registries].

I don't see anything about client side DTLS here.
Perhaps you meant 3.2.1.3: DTLS Secure Link?

}   Alternatively, DANCE [dane-clients] may be used with a DET's DNS
}   lookup to retrieve a TLSA RR [RFC6698] with the DET's HI encoded in
}   PKIX SubjectPublicKeyInfo format (per [RFC7250]).  This has the added
}   advantage of the full DET is sent in the DTLS exchange as part of the
}   DET FQDN for DANCE.

So, I'd say you need to tell us what kind of TLSA you expect to see.
I think you want certtype=3/1?  I guess that's what SubjectPublicKeyInfo
format is intended to express?

You mention that you think that starting the DTLS connection over WiFI and
then moving it to some other lower-power link.   I don't know if DTLS
officially supports this (port numbers are not part of the hash, so it should
work), but I'll just say that this is actually difficult to do with typical
(D)TLS libraries.   Not impossible, but it takes some deep knowledge.
More specifically, what I'm saying is that it might be very hard to do on a
mobile device, and might be impossible on iOS.

    > In Sec 5.6 of draft-ietf-drip-registries

    > We get where the TLSA RR is created as part of the UAS registration. 
    > Text here needs lots of help, I have already sent off one set of
    > changes to the editor.

I agree that what's there is inadequate.
It seems that it shouldn't speak about HIs if this is about *DTLS*
Or maybe I'm confused.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-