Re: [Anima] Extending GRASP messages and signing GRASP multicasts
Toerless Eckert <tte@cs.fau.de> Tue, 23 August 2022 09:56 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17DCC1526EF for <anima@ietfa.amsl.com>; Tue, 23 Aug 2022 02:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 X3n6eMrjXybb for <anima@ietfa.amsl.com>; Tue, 23 Aug 2022 02:56:26 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (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 942DAC14F73E for <anima@ietf.org>; Tue, 23 Aug 2022 02:56:25 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id C585B58C4B1; Tue, 23 Aug 2022 11:56:20 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id B74504EB828; Tue, 23 Aug 2022 11:56:20 +0200 (CEST)
Date: Tue, 23 Aug 2022 11:56:20 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>, Carsten Bormann <cabo@tzi.org>
Message-ID: <YwSkRN80Od9PR4Dt@faui48e.informatik.uni-erlangen.de>
References: <5657e3dd-7e44-6105-9847-e0f2f0e1b3d7@gmail.com> <Yv4NjyfhSbXmW25c@faui48e.informatik.uni-erlangen.de> <E2CCD85C-6E92-4E01-8487-D70A9DEEFA8F@tzi.org> <Yv4RfV8y1cO2w7KU@faui48e.informatik.uni-erlangen.de> <B5DF1954-3A89-4C84-A64F-4415F010ABF2@tzi.org> <15602.1660842563@localhost> <0c876d44-19a7-a2ad-1eda-657594895ba7@gmail.com> <24589.1661026866@localhost> <YwMop8d/KbFxy0LX@faui48e.informatik.uni-erlangen.de> <d73363ba-a1be-c825-168b-0e7135fc47f1@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d73363ba-a1be-c825-168b-0e7135fc47f1@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ZJN3-y478bXm6a-dOtjpaNBci-o>
Subject: Re: [Anima] Extending GRASP messages and signing GRASP multicasts
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2022 09:56:28 -0000
On Tue, Aug 23, 2022 at 10:57:44AM +1200, Brian E Carpenter wrote: > > In my reading of rfc8990 CDDL, an M_FLOOD message with an appended > > signature would NOT be parsed as an rfc8990 flood-message CDDL name, > > which in my book means it wouldnot be an rfc8990 flood message. Aka: > > i do not see a way how _any_ encoding of a new signature option (or for > > that any option) could be included into a flood-message so that prevous, > > rfc8990 only implementations would still receive and interpret this > > message as a flood message, but ignore the (signature) option. > > I don't agree, but I think is due to a fundamental question of how one > interprets CDDL. It isn't a syntax definition that MUST be adhered to. > It's only a data definition language. If instead of CDDL, we would specify GRASP with ASCII art, would you also say that the ASCII art is advisory, but not normative ? I don't think this was ever how we thought of the ASCII art. I think it was always mandatory, and if the ASCII art did not match what the protocol message should look like, then that was a bug in the ASCII art. Therefore, i argue that the CDDL needs to be as mandatory as ASCII art is in IETF RFC, or it really does not make sense to use CDDL. > As far as I know, people don't > implement CBOR based protocols to adhere to a CDDL spec. People do not implement IETF protocols to adhere to the ASCII art of the IETF protocol RFC ? > It's different in that respect to, say, a compiler writer using recursive > decent through a BNF spec. Having played recently with two other > formal definitions and corresponding implementations (the URI spec for > rfc6874bis, and the SVG spec for RFC7996), I'm pretty sure that CDDL > is different in that respect. I am pretty sure there is also no automated tool-chain that can compile code from ASCII art. But that does not mean that the hand written code will not comply to the ASCII art. Aka: tool chains are irrelevant for making the CDDL as normative as ASCII art is/was. > That said, it wasn't until after my second coffee today that I > really got the .within stuff right. However, each occurrence of "any" > in the CDDL seems to signal a place where the code has to be very > pragmatic, during both the encoding and decoding of a message. Not really. The better we make our RFCs in being very explicit how to handle the any, the less the code has to be pragmatic. See also draft-iab-protocol-maintenance Aka: we need to be as explicit in specifying reaction to any variation of a received message as we can in the RFC and not punt to coders with wishy-washy terms like "postel principle". To that extend, it is best to define appropriate CDDL names capturing the different sub-structures of a message that have to be handled differently. Aka: those that can be ignored, or those that would lead to rejection of message or the like. In this respect, i think CDDL makes life a lot easier than ASCII art, but we simply need to write the right CDDL names and then define in text the desired reception semantic against those CDDL names. > > I also do not think that we have good normative text in rfc8990 to > > mandate that such an option MUST be ignore upon receipt. In fact, in our > > discussions so far, we have not come up wih a generic encoding proposal > > to distinguish options that MUST be ignored vs. those that MUST cause > > ignoring or raising error against the message itself. That second goal > > could IMHO only be achieved with a new MESSAGE_TYPE in rfc8990. > > I believe that is correct. If you send an unknown message, it will > be dropped, and if unicast, the recipient MAY send M_INVALID. > (Section 2.8.2 of RFC8990) Well, my main point is that if someone sense an M_FLOOD message with a signature option at the end of the message, then it will not be recognized as a flood-message by an RFC8990 CDDL compliant receiver (that does not know about any signature option). This is IMHO what we must fix by introducing those e.g.: *grasp-option to the already defined messages. Unless a CDDL expert tells me i am syntactically wrong. > If we want a signature to be mandatory-to-verify, it needs a new > message type. That's an open question for the WG. Agreed. My opininion is that the mandatory-to-verify is not at the level of the flood-message, but at the objective definition level. Aka: I would want to define DNS-SD objectives that MUST be signed, and where also the certificate of the signer MUST meet certain criteria. With that use-case in mind, it would IMHO make sense to add to the signature draft also a definition of that certificate objective with which the certificate could be flooded. After all, without knowing a certificate, one can not validate the signature, and i hate if we have only handwaiving, for how the recipient could learn the certificate. After all, if i flood some objective with signature (for example a service announcement), and the only way how to learn the certificate is to open a grasp/TLS connection to the originator (because TLS gives me the cert and also validates it), then we have just created a DDoS attack against a third party: I originate a signed GRASP DNS-SD announcement for that poor third-party, that will then receive a lot of TLS connection attempts from all other nodes. Cheers Toerless > > explicitly introduce a new GRASP header field "sender ttl" which is not > > modified during flooding but would be used by final receiver to > > "reconstitute" the ttl field to then validate the CBOR. > > > > Any benefits you think this approach would have ? > > My reply: no. I think the detached mode works better. > > > > > > > 4. We don't claim to have solved the general problem of key > > > > distribution for multicast destinations, but in the ACP context it > > > > seems likely that we can flood out the necessary public keys. > > > > > > I feel confident that for a number of use cases that this won't be an issue, > > > and that we can leverage the BRSKI enrollment process to get any application > > > specific keys that we need. > > > > Many network designs start with centralized servers and even struggle with > > redundancy/failover of them. In ANIMA/ANI, we should always start with the > > basic technology providing fully distributed mechanisms, such as the flood > > message. When we then see cases where we can only scale futher by having > > "coordination agents", then it is trivial to build them. > > > > Aka: If we had thousands of ANI nodes wanting to announce services, then we > > would want to have some election mean for some of them to become > > "coordination agents", so the thousands of nodes just send (unicast) to those > > "coordination agents", and these coordination agents then flood. (ASA/AF) > > > > This is pretty much what the redundant server based solutions do, except > > that in the IoT space, they often have very ad-hoc rules who can be such > > a server/coordination-agent. In ANI, we could ad-hoc say that if you're > > a registrar, you do also do other coordination. Such as validating and > > reflecting service announcements. > > > > All in good time. signature option is the most fundamental work to start with. > > Agreed. > Brian > > > > > Cheers > > toerless > > > > > > > > -- > > > Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) > > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > > > > > > > > > > > -- --- tte@cs.fau.de
- [Anima] Extending GRASP messages and signing GRAS… Brian E Carpenter
- Re: [Anima] Extending GRASP messages and signing … Michael Richardson
- Re: [Anima] Extending GRASP messages and signing … Toerless Eckert
- Re: [Anima] Extending GRASP messages and signing … Brian E Carpenter
- Re: [Anima] Extending GRASP messages and signing … Toerless Eckert
- [Anima] Signing GRASP objectives [Was: Extending … Brian E Carpenter
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] Signing GRASP objectives [Was: Extend… Sheng Jiang
- Re: [Anima] Signing GRASP objectives [Was: Extend… Toerless Eckert
- Re: [Anima] Signing GRASP objectives [Was: Extend… Carsten Bormann
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] Signing GRASP objectives [Was: Extend… Brian E Carpenter
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] Signing GRASP objectives [Was: Extend… Toerless Eckert
- Re: [Anima] Signing GRASP objectives [Was: Extend… Toerless Eckert
- [Anima] ACP vs. Data plane Re: Signing GRASP obje… Toerless Eckert
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] Signing GRASP objectives [Was: Extend… Michael Richardson
- Re: [Anima] ACP vs. Data plane Re: Signing GRASP … Michael Richardson
- [Anima] Consolidated floods [was Signing GRASP ob… Brian E Carpenter
- Re: [Anima] Consolidated floods [was Signing GRAS… Michael Richardson
- Re: [Anima] Consolidated floods [was Signing GRAS… Brian E Carpenter
- Re: [Anima] Consolidated floods [was Signing GRAS… Toerless Eckert
- Re: [Anima] ACP vs. Data plane Re: Signing GRASP … Toerless Eckert
- Re: [Anima] Consolidated floods [was Signing GRAS… 蒋胜
- [Anima] session-id as epoch-id (was: Re: Signing … Toerless Eckert
- Re: [Anima] Consolidated floods [was Signing GRAS… Brian E Carpenter
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Brian E Carpenter
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Toerless Eckert
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Brian E Carpenter
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Michael Richardson
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Michael Richardson
- Re: [Anima] session-id as epoch-id (was: Re: Sign… Toerless Eckert