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

[Eric Rescorla <[e-mail]>]

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.

-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]>>>
> >      >     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>=[e-mail]
> >     <mailto:[e-mail]>>
> >      >             *Date:* 2025-03-29 19:19
> >      >             *To:* [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>; IETF SAAG
> >      >             <mailto:[e-mail] <mailto:[e-mail]>>
> >      >             *CC:* [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]>>
> >      >         To unsubscribe send an email to [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]>>
> >      >     To unsubscribe send an email to [e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >
> >
>