Subject: [Rats] New Version Notification for draft-voit-rats-trusted-path-routing-02

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 10 Jun 2020 20:13:15 +0000

Of general interest in this draft the definition of a Trustworthiness Vector 
<https://tools.ietf.org/html/draft-voit-rats-trusted-path-routing-02#section-3.2> 
which contains a ordered list of Trustworthiness Levels.  This vector is 
returned within Attestation Results, and is actionable by a Relying Party.

Eric

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Wednesday, June 10, 2020 3:59 PM
To: Eric Voit (evoit) <[email-masked]>
Subject: New Version Notification for 
draft-voit-rats-trusted-path-routing-02.txt

A new version of I-D, draft-voit-rats-trusted-path-routing-02.txt

has been successfully submitted by Eric Voit and posted to the IETF 
repository.

Name:                  draft-voit-rats-trusted-path-routing

Revision:              02

Title:                     Trusted Path Routing

Document date:               2020-06-10

Group:                  Individual Submission

Pages:                  21

URL: 
<https://www.ietf.org/internet-drafts/draft-voit-rats-trusted-path-routing-02.txt> 
https://www.ietf.org/internet-drafts/draft-voit-rats-trusted-path-routing-02.txt

Status: 
<https://datatracker.ietf.org/doc/draft-voit-rats-trusted-path-routing/> 
https://datatracker.ietf.org/doc/draft-voit-rats-trusted-path-routing/

Htmlized: 
<https://tools.ietf.org/html/draft-voit-rats-trusted-path-routing-02> 
https://tools.ietf.org/html/draft-voit-rats-trusted-path-routing-02

Htmlized: 
<https://datatracker.ietf.org/doc/html/draft-voit-rats-trusted-path-routing> 
https://datatracker.ietf.org/doc/html/draft-voit-rats-trusted-path-routing

Diff: 
<https://www.ietf.org/rfcdiff?url2=draft-voit-rats-trusted-path-routing-02> 
https://www.ietf.org/rfcdiff?url2=draft-voit-rats-trusted-path-routing-02

Abstract:

   There are end-users who believe encryption technologies like IPSec

   alone are insufficient to protect the confidentiality of their highly

   sensitive traffic flows.  These end-users want their flows to

   traverse devices which have been freshly appraised and verified.

   This specification describes Trusted Path Routing.  Trusted Path

   Routing protects sensitive flows as they transit a network by

   forwarding traffic to/from sensitive subnets across network devices

   recently appraised as trustworthy.

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 14 Jun 2020 14:30:06 -0700

> returned within Attestation Results, and is actionable by a Relying Party.

I wonder if this usage could be syncrhonized with the RFC 8485 "Vector of
Trust".

-Ben

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 15 Jun 2020 22:26:36 +0000

Hi Ben,

> From: Benjamin Kaduk. June 14, 2020 5:30 PM
> 
> > <https://tools.ietf.org/html/draft-voit-rats-trusted-path-routing-02#s
> > ection-3.2> which contains a ordered list of Trustworthiness Levels.
> > This vector is returned within Attestation Results, and is actionable
> > by a Relying Party.
> 

Thanks for pointing this out, I had not seen it. And it is interesting.  A
few initial thoughts...

(1) The universe of RFC8485 Component Dimensions does have a partial overlap
with my draft beyond the reuse of the 'vector'.   For example Identity
proofing and assertion presentation are things RATS cares about.  RATS also
cares about 'credential' lifecycle.  

(2) There are many significant domain of claims related to attestation which
are not covered in RFC8485.    E.g.:
(a) whole categories of appraisal assertions such as 'hw-authentic',
'boot-verified' or 'file-blacklisted' would need brand new 'component
dimensions'.   (Note: RFC8485 does allow other RFCs to grow additional
contexts, so perhaps this would be ok, this is of assuming someone is
willing to steward this language across many domains.)
(b) The lifecycle of Attestation Results beyond credentials quite important
with RATS.

(3) RFC8485 suggests formal codes for the level of assurance of assertions
being made.  This would mean that the language of Attestation Results should
be very rich.  In fact it should be far richer that the small handful of
simple human-understandable identities which I proposed in my draft.

With this in mind, I have generalized your question to be: how formal should
the language of Attestation Results be?   In the end, it wouldn't be too
hard to map my draft's YANG identities into *new/extended* RFC8485 vector
constructs.   But I am not yet able to see lots of immediate value.  

The first question I need to look at from the perspective of
routers/switches is how useful it would be to have an expandable standard
taxonomy and encoding for Appraisal Results.  An early guess would be that
someone who has open source code/expertise in formally expressing Appraisal
Results would be better positioned to see if this might be worthy of a draft
submission.  

Or said another way: if somebody has the expertise and desire to drive an
IETF-wide appraisal results language beyond the RFC8485 starting point, I
would happily map my very simple constructs into that language.

Thanks,
Eric

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Jun 2020 16:11:59 -0700

Hi Eric,

>From memory, I think it even encourages such growth, not just allowing them.

> constructs.   But I am not yet able to see lots of immediate value.  

That's fair.  I certainly don't have an answer in mind, myself :)

> would happily map my very simple constructs into that language.

Understood.  Thanks for reading and thinking about it!

-Ben