Re: [Last-Call] [Drip] Iotdir last call review of draft-ietf-drip-arch-22

Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx> · Wed, 11 May 2022 10:36:29 -0400



    I have been thinking on this BT 4.x 5.x writing conundrum.

    
    In my opinion, only the first use should we say 4.x and 5.x with
    wording that henceforth, only 4 and 5 will be used for
    'simplicity'.  the '.x' is not needed in most cases, as it adds
    nothing.  What we use in BT is available (so far) in all variants. 
    And IF a new variant comes out that causes problems, what are we
    going to do, publish an errata on which variant scan be used?  We
    would have to do that anyway.

    
    ERGO:  only 4.x and 5.x in first use.  Then only 4 and 5.

    
    My view.

    
    Bob

    
    On 5/11/22 10:09, Thomas Fossati wrote:

    
        Hi
            Stuart,
         
        >
            Thanks for the review! I was asked to address one of your
            nits,
         
        Thank
            you!
         
        > all
            of your other points having been addressed previously by
            others
        > (we
            think/hope).
         
        I
            haven't seen any reply from your co-authors and, unless I
            missed it,
        there
            was no publicly visible updates to the draft version that I
        reviewed
            (-22), so I cannot confirm nor deny :-)
         
        >
            "Bluetooth 4.x" and "Bluetooth 5.x" are intended to
            distinguish
        >
            between those two major versions, which have differences
            motivating
        >
            different Broadcast RID message encapsulation, but imply
            concisely
        >
            that Broadcast RID is insensitive to the minor versions.
         
        Sure.
         
        >
            ASTM F3411 requires that if a Broadcast RID sender uses any
            form of
        >
            Bluetooth, it must use 4.x, with additional use of 5.x being
            optional.
        > The
            corresponding ASD-STAN for Direct RID states the reverse.
            Thus
        >
            effectively any implementation intended for international
            use must
        >
            concurrently transmit over both 4.x and 5.x.
         
        !
         
        > The
            Bluetooth specs are voluminous: attempting to cite all those
            that
        >
            apply here would be quite a rabbit hole; I personally would
            prefer to
        >
            cite only ASTM F3411 and let the diligent student follow the
            reference
        >
            trail.
         
        Sounds
            reasonable..
         
        >
            Will our editing the draft to consistently use the forms
            "4.x" and
        >
            "5.x" suffice?
         
        Yes.
         
        Cheers,
            t
         
         
        > On
            3/27/2022 1:44 PM, Thomas Fossati via Datatracker wrote:
        >
            > Reviewer: Thomas Fossati
        >
            > Review result: Ready with Issues
        >
            >
        >
            > This is a great document and fun to read.  Thank you
            authors!  I
        >
            > have tried to highlight a few small things that could
            be articulated
        >
            > a bit more from an IoT perspective but overall I have
            no major
        >
            > concerns with it, except a tangential thing around the
            document
        >
            > intended status (see "Issues" below.)
        >
            >
        >
            > # Issues
        >
            >
        >
            > * The charter says: "the WG will propose a standard
            document that
        >
            > describes the architecture […]" but the status is
            informational.  I
        >
            > am pretty sure informational should be appropriate, but
            highlighting
        >
            > a potential disconnect.
        >
            >
        >
            > # Comments
        >
            >
        >
            > * In some IETF circles (e.g., RATS & TEEP)
            "attestation" has a
        >
            > precise meaning, which is quite distinct from the DRIP
            definition
        >
            > "[…] normally used when an entity asserts a
            relationship with
        >
            > another entity".  Specifically, unless the signing key
            is derived
        >
            > from the measured boot state (a la DICE), or the claims
            are of a
        >
            > certain kind, the process that this doc names
            "attestation" is not
        >
            > what is meant usually.
        >
            >     => Maybe add a few words to Section 2.2 to
            clarify the
        >
            >     distinction between DRIP attestation and RATS's,
            e.g., by adding
        >
            >     a disclaimer similar to that already associated
            with DRIP certs.
        >
            >
        >
            > * Apropos "remote attestation", I am wondering whether,
            given the
        >
            > type of endpoints considered in the architecture - and
            in particular
        >
            > provided their increased exposure to physical
            compromise, and the
        >
            > potentially large impact on the overall system and
            beyond - the
        >
            > architecture should provide explicit channels for
            securely conveying
        >
            > the verification of the installed and booted firmware
            (as well as
        >
            > any other relevant trust metrics)?
        >
            >
        >
            > * I haven't read the rest of the DRIP docs, so I am not
            sure why is
        >
            > EdDSA specifically mentioned in Section 3.2.?  Is this
            a requirement
        >
            > or just an example?  I guess the latter, but checking
            just in case.
        >
            > And apropos that, in light of fault attacks on
            deterministic ECDSA
        >
            > and EdDSA [0] that are potentially easier to carry out
            against UAs
        >
            > (BTW, how cool is a fault attack w/ private key
            exfiltration carried
        >
            > out by a chasing drone?) maybe it's worth adding to the
            security
        >
            > considerations some words around physical attacks and
            their impact
        >
            > on the choice of signature algorithms?
        >
            >
        >
            > * It'd seem that, given the very low bandwidth, DoS (as
            well as
        >
            > Denial of View) attacks on communication involving the
            UA should be
        >
            > quite easy to mount?  Maybe worth spending some words
            on the
        >
            > argument to describe what the threats are and which
            mitigations are
        >
            > available.
        >
            >
        >
            > * This is a question more than anything else: given the
            constrained
        >
            > nature of UAs, I was wondering whether it is envisaged
            that the
        >
            > end-to-end network path will be realised with the use
            of more
        >
            > capable (trusted) proxy nodes?  If so, there may be a
            few security
        >
            > and privacy considerations to be added.
        >
            >
        >
            > # Nits
        >
            >
        >
            > * AAA is usually intended as "Authentication,
            Authorization, and
        >
            > Accounting" (see also [1]), whereas here it's got four
            new A's:
        >
            > Attestation, Access Control , Attribution, Audit :-)
        >
            >      => Maybe change it to 7A, A7, AAA+ or similar?
        >
            >
        >
            > * In Section 2.1, the following terms are already in
            the most recent
        >
            > "RFC Editor Abbreviations List" [1] and can be removed:
        >
            >      * EdDSA
        >
            >      * HIP
        >
            >      * HIT
        >
            >      * HI
        >
            >
        >
            > * Some typographic inconsistency around Bluetooth: Is
            it 4 or 4.x?
        >
            > 5 or 5.x?
        >
            >      => Stick to one format. (Also maybe add an
            explicit reference
        >
            >      to the Bluetooth specs.)
        >
            >
        >
            > [0] https://eprint.iacr.org/2020/803
        >
            > [1]
            https://www.rfc-editor.org/materials/abbrev.expansion.txt
        >
            >
        >
            >
        >
            >
        > --
            
        >
            -----------------------------------------
        >
            Stuart W. Card, PhD, Principal Engineer
        > AX
            Enterprize, LLC  www.axenterprize.com
        >
            4947 Commercial Drive, Yorkville NY 13495
        > 592
            Hangar Road, Rome NY 13441
        > 
        
           
      IMPORTANT NOTICE: The contents of this email and any attachments
      are confidential and may also be privileged. If you are not the
      intended recipient, please notify the sender immediately and do
      not disclose the contents to any other person, use it for any
      purpose, or store or copy the information in any medium. Thank
      you.
      

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call