Re: [Rats] draft-ietf-rats-architecture-12

Daniel Migault <mglt.ietf@gmail.com> Wed, 03 November 2021 21:51 UTC

Return-Path: <mglt.ietf@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 3439D3A1253 for <rats@ietfa.amsl.com>; Wed, 3 Nov 2021 14:51:15 -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 jOnhKP0s3rrl for <rats@ietfa.amsl.com>; Wed, 3 Nov 2021 14:51:10 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 0FADE3A1255 for <rats@ietf.org>; Wed, 3 Nov 2021 14:51:10 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id b3so7166727uam.1 for <rats@ietf.org>; Wed, 03 Nov 2021 14:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFIv4JjyMqQOLb7TqJXvfvi7PDZkCWbh0tFsnPGGzjI=; b=mUivZcO331faOWVCRgf4P0rb9ata/wRHdrMO3K0LPXeKzV+tJMIs44j6ROdRGxefFQ CWTdW472a92NfvgwtG8A9GWUbegEHvZcoEU3D9yniUQWXnOmFFf5s6nj91uLY7+XAijj /S1VDVwfIPwQWO//kaUf+eSX1GCtVFrElrZpd0uzjFmrEFDZcqfD9d8phEu6Xi235pld eifTl24tbiRCyGjaFNZeDvAFhiW74FxVXAlmoaPRV7+O7ML9UOJcuJwAR7KVVOsaMYXf y9ARF/oxax1qcznCivVUVJ4sk2N329VkzlTSN+7hXL7owZZtoK23V1TJw18ZxyFnCuMx AJNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFIv4JjyMqQOLb7TqJXvfvi7PDZkCWbh0tFsnPGGzjI=; b=6xQWYoPnntvSV/KP27hkZs4pW/EgQBB+Zyu8oApqhsFs5FGff61Lrqb8aJdS0277Zj 9mOJVz9qqzM4+qFQUr7rkgK/VOPOj5NEIfZHrO7MMMQcGiyAxNCoMVkJXnAXe2ma0VXk 0pDmkaMjWooqaJHNPUA7NLQLwhXKWAlykGYscN6XnIhJ4vvmZ8C0h1TWz+OYV/Gfni1y BwNZbaNVR/aJAsTRup8f4yryQO4Wa1bxc8z4tPq0qIfFOYMbcPGFItrhVEWCtfBPa5gf a4E7hPybUukPgkvKdDBKueiC2AlIIU9AI9/x7VrE45rVmcP8CIgjfBYRPHVLRWvIx92m gjtg==
X-Gm-Message-State: AOAM530pyfnDRPxcUIyrSOFXr7X0Jtr/ExZT2iGeXLjYBN0YL+MNhWP8 4MG32wbMp1ZApW8gRFHJFbcWBY/w/OvuA5e1y90=
X-Google-Smtp-Source: ABdhPJyKSLniAoVUfwLZNoGMMbkv7tdB3+YXurqgo+0I/aFQi91M28lqJfcGmhQMIAg9C6eGxFwKn2XPtW86VJJmq5g=
X-Received: by 2002:a67:ed87:: with SMTP id d7mr55783281vsp.30.1635976268408; Wed, 03 Nov 2021 14:51:08 -0700 (PDT)
MIME-Version: 1.0
References: <CADZyTk=ZbSUYxywzVONYjo59JVf56r8kAhpKqtXgE2=k2uZ5uA@mail.gmail.com> <8748.1635932817@localhost> <F071BD6A-B713-478D-9896-F745AD83D145@intel.com>
In-Reply-To: <F071BD6A-B713-478D-9896-F745AD83D145@intel.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 03 Nov 2021 17:50:57 -0400
Message-ID: <CADZyTkmc9p4BuKcEmdDtt2d2hV3Zh1syMgFo_enw+GCuEdT6ng@mail.gmail.com>
To: "Smith, Ned" <ned.smith@intel.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056ed7305cfe9685f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ucXsHhIWjLA7tEd7Wskq3ogcxmI>
Subject: Re: [Rats] draft-ietf-rats-architecture-12
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: Wed, 03 Nov 2021 21:51:15 -0000

Thanks for the response,

I did not find untrusted claims in the text. What I wanted to raise is that
trusting the Attesting Environment may not be sufficient to trust the
claims and that the trust is conditional to the ability of the Attesting
Environment to get non tampered claims. If these are part of the same
hardware that is easier to understand. If Target Environment and Attesting
Environment are different pieces of hardware we also need to trust the
Target E and the communication between Target E and Attesting E. I assumed
Target E and and Attesting E were different pieces, but maybe I was wrong
and this is not the common use case.

I agree that attested claim can be seen as evidence. Actually the text they
are not signed and my questions started as what a signed claim could be. So
I tend to say the confusion is on me.

I think some of my questions came from the fact that I started reading
thinking of evidence as a signed hash of all claims.

Yours,
Daniel



On Wed, Nov 3, 2021 at 4:43 PM Smith, Ned <ned.smith@intel.com> wrote:

> I looked for use of the term 'untrusted claims' in reference to Fig. 2 in
> rev 12 but couldn't find it.
>
> If the conclusion after reading the section is that Evidence is
> 'untrusted' it might be more correct to regard Evidence as 'unverified' or
> 'un-appraised' Claims?
>
> I don't think there is meaning behind terms like 'attested evidence' as it
> is the same as just 'Evidence'. However, 'attested claims' could be
> considered synonymous with Evidence I suppose.
>
> On 11/3/21, 2:47 AM, "RATS on behalf of Michael Richardson" <
> rats-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
>
>
>     Daniel Migault <mglt.ietf@gmail.com> wrote:
>         > """
>         > See Section 8 for further discussion of the conceptual messages
> shown
>         > in Figure 1. ## Two Types of Environments of an Attester
>         > """
>
>     Bizarre. A newline missing.
>     It seems to be fixed in the github copy already.
>
>         > From Figure 2.
>
>         > The trust associated with the Evidence is related to the trust
> of the
>         > Target Environment as well as the communication of the Claims
> from the
>         > Target Environment to the Attestation Environment. I think some
>         > clarification/explanation may be added. My current reading is
> that
>         > Evidence are attested untrusted claims which is not so useful.
>
>     There are proposals to make this diagram more complex.
>     The editors don't want to do that because the diagram is already pretty
>     subtle.
>
>     I don't understand your statement,
>       "are attested untrusted claims"
>
>     I don't understand the word "untrusted" here.
>     I think that it's pretty critical if we've confused you right here.
>
>         > section 3.1
>
>         > """
>         > Normally, Claims are  not self-asserted,
>         > """
>
>     (that's section 3.2 in my copy.  Maybe the above editorial issue
> screwed up
>     the section number.)
>
>     This section is about _Layered Attestation Environments_
>
>         > seems to me a bit unclear, more especially, when a claim
> contains a value
>         > of a register, I see the register as part of the Target
> Environment and the
>         > register provides its value. I tend to see the register as self
> asserting
>         > its value. Assert in the text seems to be related to the trust
> associated
>         > with the value of the claim.
>
>     I don't understand your comment here.
>     Assert isn't used that much in the text.  It is used in the definition
> of
>     "Claim", and in the passport example, and then not again.
>     We sign evidence in the Attesting Environment in order to communicate
> the
>     value securely.  That can be EAT, TPM/Charra, UCCS+TLS, ...
>
>         > If so, that assertion (or trust) results both
>         > in the trust of the Attesting Environment (system + attesting
> keys) as well
>         > as the system that enables the communication of the Claims to
>         > the Attesting Environment.
>
>
>         > Am I correct when I consider the system + keys as the root of
> trust ?
>
>     Yes.
>
>         > Claims about a root of trust typically are asserted by an
> Endorser.
>
>         > So Figure 1 shows the Endorser interacting with the Verifier.
> Figure 2
>         > shows the interaction within the Attester and shows Claims being
> exchanged
>         > between the Target Environment and the Attesting Environment
> while
>         > Attesting Environment and Verifier exchange Evidences.
>
>     Figure 2 is a blow up of the interaction on the lower-left of Figure 1.
>
>         > I am wondering if
>         > that Claims should be replaced by Evidence or if the intention
> is to say
>         > that Evidence is carrying/generated Claims trusted by a root of
> trust -
>         > which in this case is associated to the Target Environment and
> not the
>         > Attesting Environment.
>
>        Evidence:  A set of Claims generated by an Attester to be appraised
>           by a Verifier.  Evidence may include configuration data,
>           measurements, telemetry, or inferences.
>
>     Claims are in general, not signed/integrity-protected.
>     Evidence is protected in some way when they are communicated.
>     It's also more than one key/value.
>
>         > """
>         > The
>         > final Evidence thus contains two sets of Claims: one set about
> the
>         > bootloader as measured and signed by the BIOS, plus a set of
> Claims
>         > about the kernel as measured and signed by the bootloader.
>         > """
>
>         > I understand that the set of claims are combined together with
> for example
>         > a hash function. In other words, Evidence is not (necessarily) a
> list of
>         > claims that can easily be extracted from the Evidence.
>
>     Extending a single PCR in a TPM results in a single Claim.
>     The Claims are not fed into the TPM.
>     Any hash (ECDSA w/SHA256 for instance) involved in signing the
> Evidence, is a
>     property of the signing algorithm, and not part of the Claim.
>
>         > If my understanding is correct, I would maybe clarify
> "contains". I also
>         > have the impression cascading carries the notion of recurrence
> where one
>         > level includes all levels below - but that is my own perception.
> Overall I
>         > have the impression that [claims_a, claims_b] can have multiple
>         > representations including claim_c = hash(  [claims_a, claims_b]
> ) or
>         > claim_d = [claims_a, claims_b]. In both cases they represent the
> set of
>         > claim_a and claim_b.
>
>     Yes, that's possible, but I think you are mixing implementation into
> architecture.
>
>         > 4.2
>
>         > """
>         > Evidence:  A set of Claims generated by an Attester to be
> appraised
>         > by a Verifier.  Evidence may include configuration data,
>         > measurements, telemetry, or inferences.
>         > """
>
>         > This is mostly what is just mentioned above. To me a set of
> claims is s = (
>         > claim1, claim2, ..., claimn) and I have the possibility to take
> s[0], but I
>         > have the impression that the set here is more abstract and is
> represented
>         > by the hash(s). Myabe that worth clarifying how the set is
> represented.
>
>     No, that's not correct.
>
>         > section 7.4
>
>         > 1.  The key material used to authenticate and integrity protect
> the
>         > conveyance channel is trusted by the Verifier to speak for the
>         > Attesting Environment(s) that collected Claims about the Target
>         > Environment(s).
>
>         > The text does not mention the trust in the Claims. I have the
> impression
>         > that it also conveys some trust in the claims.
>         > In the case of the BIOS, we do put similar trust into the
> hardware to load
>         > properly the BIOS stored into the ROM as we trust the
> attestation keys
>         > stored into the hardware. This, in my view, makes the states
> provided by
>         > the TPM trusted.
>
>     I can't really parse what you mean.
>
>         > section 8.4
>
>         > _Strength of Function_ this is a markdown notation I suspect.
>
>     Yes, and in text form, that's how we represent italics, just like in
> email.
>     In HTML it shows up in italics.
>
>         > By default, the Relying Party does not believe the Attester to be
>         > compliant.  Upon receipt of an authentic Attestation Result
>
>         > I do not see any reason to perform attestation if the Attester
> is known to
>         > be compliant. I am wondering if "by default" is appropriated or
> should be
>         > instead replaced by something around Upon starting an
> attestation, the
>         > Relying....
>
>     In the beginning ("by default"), the universe was without form, and
> all Attesters were
>     untrusted.  Then, on the first day, God created the Verifier, and used
> it to
>     evaluate Evidence, and separated the void into the Trusted and the
> Untrusted.
>
>         > It is a bit unclear to me what authentic means
>
>     It means, for instance that the signature has checked out.
>     But, not every system uses signatures directly.
>     It could also indirect through session security, e.g.: TLS
>
>         > Section 9:
>
>         > 9.  Claims Encoding Formats
>
>         > The section is mostly focused on Evidence and Attestation
> Results, not so
>         > much on Claims. That said, the discussion is a generic
> discussion over
>         > which format to use and this can be extended to Claims as well,
> though in
>         > some cases Claims may have proprietary formats.
>
>         > What is unclear to me in the section is the relation between
> Claims and
>         > Evidence, and I think that is related to previous comments.
>
>     It seems that our attempt to be abstract has caused confusion.
>
>         > Here I am reading Evidence as a set of Claims.
>
>     which is the definition of it :-)
>
>         > So I am wondering if we expect
>         > Evidence format to be a list of Claims in which Claims can be
> either built
>         > from the Attesting Environment or provided by a Attesting Target.
>         > Typically
>         > I do see measurements as new Claims generated by the Attesting
> Environment.
>         > I agree that in both cases these are inside the Attester.
>
>     Evidence = signed(claims)
>
>         > section 10.
>
>         > All timekeeping methods seem to me to have an implicit period
> when the
>         > information is valid - I am basically thinking of it as a TTL.
>
>     That's true.
>
>         > Using Epoch
>         > ID, I have the impression that a new ID indicates a new time
> slot, so I am
>         > wondering if blocking the time distributor does not keep the
> device into
>         > the past and makes possible replay attacks.
>
>     Yes that's correct.
>     Within an epoch we can not tell relative freshness of evidence.
>     The network could re-order things for instance.
>     But, evidence is signed, and it's usually idempotent.
>     Replaying the evidence by an attacker would be indistinguishable from a
>     network that duplicated/retransmitted packets.
>
>     {ps: I didn't open any issues on your review yet, but I'd like to}
>
>     --
>     Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
>                Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
>

-- 
Daniel Migault
Ericsson