Re: [Rats] comments on draft-birkholz-rats-uccs

Ira McDonald <blueroofmusic@gmail.com> Mon, 17 August 2020 22:22 UTC

Return-Path: <blueroofmusic@gmail.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA03A12BB; Mon, 17 Aug 2020 15:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3FgOo8gClDy; Mon, 17 Aug 2020 15:22:52 -0700 (PDT)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8DF3A12AF; Mon, 17 Aug 2020 15:22:51 -0700 (PDT)
Received: by mail-vk1-xa2b.google.com with SMTP id k1so3882728vkb.7; Mon, 17 Aug 2020 15:22:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8gscst13IKBJENQzm+eZYRsdBRWct5Y+Or7d23CP8aw=; b=l7jJ+094O/zzLkoLJ3JDJzGTBwtJCLgdD97D3ou1bcS+iA8pxLQ4Whi9bVDb5zKAEw BEoxdAB5Vf98Sjy3JMP+VY38S4fHpW8bJYfTPk7KuWBAe/Caqrn4KV0pVVtEUGFEtBa5 3YkXMqP50zfkB70caynvpp1Q2omEb1+lr78MBEebtvazvTLC0QpJCrsl6fEw+0F24yY4 GmAS3apidE+CeLX/3m4Y70d6x1/RJx8vy6o9d5Wgfc/KPc2T6eFRyOZQQX8b4pETYfte 9PHECOvWHe7zKQqvpoRjBjaQ9anXh6taDesE7/ApK5RsvZAeJxr4UcnhI0YOaVW7HVZc rfFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8gscst13IKBJENQzm+eZYRsdBRWct5Y+Or7d23CP8aw=; b=HFvDVUwfKzeLuVMR/JtjzjiauoF8wYybc1i9KK85V62CBk81+5btxSzqJtsM7LRZzR q0Ui6gK80Fr6aEaWcFPGhsLtHPSBj59sa9ht4t4dMTkFJwLwCtdb7fHf/Z1RzfO3c2IG EL+ot+e5fWcpAkVFfzPWzW3mqQ6pffSLn2Y1+xsKvaCVyTU0f9gtaKoCmxtVjoS7d378 h75UompMnPpRQ77kbPbfNqzxDzlLiV2HTsh9oH3fYZBrICNkN6ebwUIctSL9FqYMhM5x t8cD/CZZPDIw8FYVWEsN/2yqRbiBD2h5HXiYKiK7JmgpS5zoXM7c4JHoRFhJvjX4mlZe qXYg==
X-Gm-Message-State: AOAM533npmxBsXSoViFsD28UWn8b4bakx+bTjIR9YWHNasavS4mKd86N sFONCb6kohmMth2VwciwThV6+dGcYmZA79iekho=
X-Google-Smtp-Source: ABdhPJzIIzCiNFsesYCgb2fz2KO85YM4OeJuNDY6lz6MscTA/bZmf1Flvi7gAuFr7aqbXO4rb9Vm0sdLq2p2eNMfz3Y=
X-Received: by 2002:a1f:9b8f:: with SMTP id d137mr9609194vke.97.1597702970849; Mon, 17 Aug 2020 15:22:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAM+R6NUya3dgpXWC11qufhKE9BcSSzG9W2W7jGDxqyRdOcrtRw@mail.gmail.com> <7e0d32a9-46d2-c9db-ac54-c241d5209b22@sit.fraunhofer.de> <016a01d674d2$edf35630$c9da0290$@augustcellars.com>
In-Reply-To: <016a01d674d2$edf35630$c9da0290$@augustcellars.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Mon, 17 Aug 2020 18:22:37 -0400
Message-ID: <CAN40gSuw+oUKUs30wARTpXwgc1i5KpUcT3VEW-6k=rQEON6gLA@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>, Ira McDonald <blueroofmusic@gmail.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Jessica Fitzgerald-McKay <jmfmckay@gmail.com>, rats@ietf.org, Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov>, draft-birkholz-rats-uccs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000008c06205ad1a3656"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_kOD0blrR8Cp51DMM75tWuIv2JE>
Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 22:22:54 -0000

Hi,

Of course Jim knows where work should be in IETF.

I also concur that ACE, but *not* COSE, could be a reasonable
alternate home for UCCS.

Cheers.
- Ira


*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Mon, Aug 17, 2020 at 4:14 PM Jim Schaad <ietf@augustcellars.com> wrote:

>
>
> -----Original Message-----
> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
> Sent: Monday, August 17, 2020 3:49 AM
> To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>om>; rats@ietf.org
> Cc: Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov>ov>; Jim Schaad <
> ietf@augustcellars.com>gt;; draft-birkholz-rats-uccs@ietf.org
> Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
>
> Thanks Jess!
>
> the discussion on where this is incubated was deliberately scoped down to
> provide:
>
> * a finite and still useful set of Security/Privacy considerations, and
> * relatively specific guidance and context on how prerequisites for usage
> look like.
>
> The concept of an UCCS tag goes beyond RATS, of course. The usage of an
> UCCS tag alas requires some application-specific "rules".
>
> That said, we will discuss this topic specifically asap. Also, Jim is now
> in CC (Hi Jim) and maybe he can weigh in on this topic?
>
> With respect to your technical comments, please give us some time to come
> back with well-formed answers. I do not want to barge ahead with half-baked
> replies :-)
>
> Viele Grüße,
>
> Henk
>
> On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote:
> > Hi, UCCS authors,
> >
> > Mike Jenkins and I reviewed the UCCS draft. Our comments are below.
> > Happy to talk through any of them with the group.
> >
> > Thanks,
> > Jess
> >
> > The intent of this draft is similar to the key concept of EST - use
> > the authentication of the secure session connection. Most schemes
> > build on this concept leave a lot of banana peels laying around, some
> > of which we describe here. In general, this does not seem appropriate
> > to the scope of RATS. We feel that COSE might be a more appropriate
> > work group to think these issues through.
>
>
> [JLS] To me COSE is exactly the wrong place to do this.  If it is not done
> in RATS then ACE would be the appropriate location.  Doing it in COSE would
> be something along the lines of "If you don't use the core technology of
> this group then you should?"
>
> >
> > - If you're using a static symmetric key for authentication (as one
> > might with highly-constrained devices), you can only authenticate a
> > net, not an entity. The receiver cannot differentiate between
> > authenticating the sender and authenticating itself.
>
> [JLS] I don't see this as being interesting for this document  The exact
> same set of problems exist if you use HMAC or symmetric encryption with
> COSE where a static symmetric key is used.  The thing that might be
> interesting would be to talk about correspondences of the secure channel
> security and the equivalent COSE objects.
>
> >
> > - The authentication happens at the secure channel termination, not in
> > the channel-contents-using application. It's important how the
> > termination process vouches the authentication to the application. (In
> > EST, this question is how the EST server vouches the requestor's
> > identity to the CA server.)
> >
> > - A TEE only helps if the TEE application can punch through the REE
> > and set up the secure channel completely on its own. If the TEE relies
> > on the REE to set up the secure channel, you might as well just
> > operate in the REE.
> >
> > - There is a comment at the end of the introduction (!) about
> > transitioning back and forth between self-protected and
> > channel-protected CWT, "in a well-defined scope". Define the security
> > characteristics of that scope or get rid of the comment. You're
> > handing someone an awful lot of rope there.
> >
> > - The claims set should be treated as ephemeral by the recipient. It
> > shouldn't be stored, and can't be forwarded except as data originated
> > by the recipient. As soon as it emerges from the secure channel, it's
> > no more valid or meaningful than any other piece of unprotected data
> > in the application environment.
> >
> > _______________________________________________
> > RATS mailing list
> > RATS@ietf.org
> > https://www.ietf.org/mailman/listinfo/rats
> >
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>