[nasr] Re: [saag] Re: NASR BOF Follow-Up

[Henk Birkholz <[e-mail]>]

On 11.04.25 15:38, Eric Rescorla wrote:
> 
> 
> On Fri, Apr 11, 2025 at 2:01 AM Henk Birkholz 
> <[e-mail]> wrote:
> 
>     On 10.04.25 21:01, Eric Rescorla wrote:
>      >
>      >
>      > On Thu, Apr 10, 2025 at 11:40 AM Henk Birkholz
>      > <[e-mail]> wrote:
>      >
>      >     On 03.04.25 21:11, Eric Rescorla wrote:
>      >
>      >      > [0] Of course you could hash the individual configuration
>     values,
>      >      > but this is much the same as publishing the configuration.
>      >
>      >     Is it? I am curious why.
>      >
>      >
>      > Because the values themselves are generally low entropy, so if you
>      > publish their hashes, then it's generally easy to determine the
>     preimage.
>      >
>      > -Ekr
> 
>     Would some salt help here (like the salted hashes in sd-cwt)?
> 
> 
> Probably not very much. What salt does is make it more difficult to 
> amortize computation
> across multiple hashed values. However, if the total number of possible 
> values
> is low (e.g., you have some configuration setting with 3 values) then 
> you can
> just exhaustively search at query time.

That makes a lot of sense - and might be another good reason not to put 
these types of Claims into Evidence. I still think it is better to 
include software components that provide the conveyance mechanism (e.g., 
a YANG server with YANG Push capability) in a TCB and then use 
successfully appraised software components for trusted telemetry to 
convey such values for evaluation.

Viele Grüße,

Henk

> 
> -Ekr
> 
> 
> 
>     Viele Grüße,
> 
>     Henk
> 
>      >
>      >
>      >     Viele Grüße,
>      >
>      >     Henk
>      >
>      >      >
>      >      >
>      >      >     It was not raised in the BoF, but I would like to
>     point out a
>      >      >     logical inconsistency at the core of the proposition
>     here: On the
>      >      >     one hand, the proponents assert that end-to-end
>     cryptographic
>      >      >     protections are not sufficient to keep endpoints safe.  On
>      >     the other
>      >      >     hand, the premise of the proposed solution is ... more
>      >      >     cryptography.  Attestations, MACSEC, etc.  So the
>     argument here
>      >      >     cannot rest on a hand-wavy "cryptography isn't
>     enough"; you
>      >     need to
>      >      >     articulate what specific risks you're addressing.
>      >      >
>      >      >     Honestly, when I read the charter for this work, I did not
>      >     initially
>      >      >     have as negative a reaction.  I initially presumed it
>     was like
>      >      >     verified SFC, and that you would do things like making
>     a firewall
>      >      >     rule a little more permissive if the flow had been
>     verified
>      >      >     upstream.  It's not implausible that there are some
>     use cases of
>      >      >     that shape.  But instead, the presentations in the BoF
>     framed an
>      >      >     impossible problem and an unworkable solution, which
>     clearly
>      >     I could
>      >      >     not support.
>      >      >
>      >      >     Hope that helps,
>      >      >     --Richard
>      >      >
>      >      >
>      >      >     On Thu, Apr 3, 2025 at 12:05 AM Meiling Chen
>      >      >     <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>      >      >     wrote:
>      >      >
>      >      >         Hi all,
>      >      >
>      >      >         We will continue to track and actively address the
>     issues
>      >     raised
>      >      >         on NASR BoF, for convenience, I have brought the Q&A
>      >     record to
>      >      >         the email list.
>      >      >         Welcome to continue discussing with those who are
>     concerned
>      >      >         about these issues.
>      >      >
>      >      >         Q1: Why is not end-to-end protection sufficient
>     and why
>      >     should
>      >      >         we care about where the traffic goes through?
>      >      >         Q2:  Why this is important to assure at the
>     network layer?
>      >      >         Q3: List actual concrete examples of existing
>     regulations.
>      >      >         Q4: List the technical requirements in detail.
>      >      >         Q5: NASR being a possible way to address pervasive
>     traffic
>      >      >         monitoring threats?
>      >      >
>      >      >         Q6: Proof of transit does not imply that the packet
>      >     didn’t exit
>      >      >         the path. ---->PoNT is out of scope.
>      >      >
>      >      >         Q7: There is work about proof of transit that has been
>      >     done in
>      >      >         SFC, what is needed to highlight what is not there (in
>      >     routing,
>      >      >         RATS, SFC PoT) which NASR will provide.-->
>      >      >
>      >      >         NASR is the joint use of attestation techncology
>     and proof of
>      >      >         transit.
>      >      >
>      >      >         Q8: What about lawful interceptions?---->
>      >      >
>      >      >         Trustworthiness as defined in RATS can attest that a
>      >     router does
>      >      >         what is supposed to do, including lawful
>     interception if
>      >     it is
>      >      >         what it is supposed to do.
>      >      >
>      >      >         Q9: There is work from RATS, like RFC 9684, that
>     can be
>      >     used in
>      >      >         NASR. Why an independent effort? Why not putting this
>      >     work in an
>      >      >         existing WG?---->
>      >      >
>      >      >         RATS is the building block to create path
>     attestation, whose
>      >      >         usage is then verified with proof of transit.
>     These two
>      >     things
>      >      >         together look out of the scope of RATS. NASR does
>     not want to
>      >      >         replace RFC 9684, but rather leverage it.
>      >      >
>      >      >         Q10: What is exactly the definition of a path in
>     NASR? BGP
>      >      >         session? Tunnel? physical links?---->
>      >      >
>      >      >         A document in PANRG has a good definition of what
>     a path is.
>      >      >
>      >      >         Q11: Trustworthiness and traffic engineering are
>     already
>      >      >         addressed in different places, so what is new in
>     NASR? ---->
>      >      >
>      >      >         The possibility for the customers to verify that the
>      >     traffic has
>      >      >         been engineered in the way they asked. How to do it is
>      >     the gap
>      >      >         NASR wants to fill.
>      >      >
>      >      >         Q12: Candidate solutions from problems exist in
>     other venues
>      >      >         (Routing security / SFC)---->
>      >      >
>      >      >         True, but they do not address the combination
>     (forwarding).
>      >      >
>      >      >         Q13: Proposed work may result in fragmentation of the
>      >     Internet,
>      >      >         including and excluding poeople?---->
>      >      >
>      >      >         No. That is the wrong terminology to use. NASR is
>     about path
>      >      >         complaint to a set of claims. Is a specific
>     service in a
>      >     limited
>      >      >         domain not a general service for the Internet.
>      >      >
>      >      >         Q14: Clarification of requirements whether the
>      >     requirement is to
>      >      >         detect nodes along the path that do not support
>     NASR?---->
>      >      >
>      >      >         No. Only have proof that traffic went through a
>     set of nodes
>      >      >         that support NASR.
>      >      >
>      >      >         Q15: Bringing the work to RATS would not work. RATS is
>      >     already
>      >      >         bloated and bringing all this work there is not
>     possible.
>      >      >
>      >      >         Q16: PoT has cryptographic cost.--->
>      >      >
>      >      >         Implementation on SRv6 shows that the cost is very
>     limited.
>      >      >
>      >      >         Q17: Remark about the scope of implementation:
>     Internet or
>      >      >         limited domain?--->
>      >      >
>      >      >         limited domain implemented at the operator level.
>      >      >
>      >      >         Q18: Need to verify every configuration (binary /
>      >     configuration
>      >      >         files / routers) in order to determine the
>     properties of the
>      >      >         path?--->This is not how remote attestation works.
>     There
>      >     is no
>      >      >         configuration shared, the configuration is
>     attested through
>      >      >         trusted third party. You share hash values that attest
>      >     the the
>      >      >         property.
>      >      >
>      >      >         Q19: Why not doing this in the SFC WG?---->Piece
>     can be
>      >     done in
>      >      >         other WG, but from a global perspective wold be
>     better to
>      >     have a WG.
>      >      >
>      >      >         Q20: For reliability, what about having multiple
>     paths?
>      >     Can it
>      >      >         be a scalability issue? ----Yes, the attribute of
>      >     multiple path
>      >      >         is included.
>      >      >
>      >      >         Best,
>      >      >         Meiling
>      >      >
>      >      >             *From:* Liuchunchi\(Peter\)
>      >      >             <mailto:liuchunchi <mailto:liuchunchi>
>      >     <mailto:liuchunchi
>     <mailto:liuchunchi>>=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >             *Date:* 2025-03-29 19:19
>      >      >             *To:* [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; IETF SAAG
>      >      >             <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >             *CC:* [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >             *Subject:* [saag] NASR BOF Follow-Up
>      >      >
>      >      >             Hi NASR, SAAG,____
>      >      >
>      >      >             __ __
>      >      >
>      >      >             Thanks everyone for participating and contributing
>      >     valuable
>      >      >             feedbacks to the NASR BOF last week! Thank you
>     Nancy and
>      >      >             Luigi for mediating a productive discussion, and
>      >     thanks Deb
>      >      >             for supervising the process.____
>      >      >
>      >      >             __ __
>      >      >
>      >      >             During the process, we had extensive
>     discussions that
>      >     showed
>      >      >             both major interests in the problem and differing
>      >      >             understanding of the objective. For example, NASR
>      >     represents
>      >      >             new use case requirements that aim to extend
>     Remote
>      >      >             Attestation benefits to the network scale,
>     providing more
>      >      >             comprehensive security visibility and behavioral
>      >     assurance
>      >      >             across network deployments to the customers.
>     But NASR
>      >     is not
>      >      >             intended, in any capacity, to serve as a
>     substitute for
>      >      >             end-to-end encryption technology, etc. ____
>      >      >
>      >      >             __ __
>      >      >
>      >      >             The poll result shows a clear consensus that
>     this is
>      >     an IETF
>      >      >             problem, but a rougher (at best) or no
>     consensus that the
>      >      >             problem is well understood. ____
>      >      >
>      >      >             __ __
>      >      >
>      >      >             To help on that, next steps we will work on a
>     dedicated
>      >      >             document that collects all valuable feedbacks from
>      >     the BOF
>      >      >             and resolve them one-by-one. Again, we
>     sincerely thank
>      >      >             everyone who contributed valuable feedbacks
>     and cares
>      >     about
>      >      >             bringing more security and transparency to
>     networks!____
>      >      >
>      >      >             __ __
>      >      >
>      >      >             Best regards,____
>      >      >
>      >      >             Peter (Chunchi) Liu____
>      >      >
>      >      >             __ __
>      >      >
>      >      >         _______________________________________________
>      >      >         saag mailing list -- [e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >         To unsubscribe send an email to
>     [e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >         <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >
>      >      >     --
>      >      >     nasr mailing list -- [e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >
>      >
>