(slight rant about encryption, sorry, also Ccing IESG because this seems to
have resulted from IESG feedback):
Which IESG feedback did raise the need to mandate encryption for GRASP in the
text block you propose ?
If this does stem from IESG feedback, i would love to know any appropriate IETF
security guideline
(RFC?) that defines this MUST as recommended for network signaling (such as
GRASP).
IMHO: I think its bogus and an annoying proliferation of PerPass concerns into
totally
different domains than end-user data. I think most network signaling works best
if it is NOT encrypted
by default because it easily breaks monitoring, diagnostics, troubleshooting,
analytics, optimizations.
IMHO, networking signaling transport MUST support authentication and SHOULD
enable this
by default. It MUST support enrcyption but SHOULD select the default for
encryption (off/on)
based on weighting monitoring, diagnostics, troublehsooting, analytics and
optimizations benefits
vs. data privacy concerns (eg: understood and documented increase in attack
surface).
Example:
- TLS with zero-encrypt is IMHO a good default for network signaling (such as
GRASP).
- ACP is a great solution to enable encryption by default because the zero-touch
handling of domain certificates does allow to easily establish trust
relationships
for "third-party" monitoring, diagnostics, troubleshooting, analytics and
optimization functions.
Thanks
Toerless
> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter <[email protected]>
> wrote:
>
> This version includes a second round of responses to IESG comments.
>
> We may not be done yet, but please check the diffs. Here are the main changes:
>
[...]
>
> <t>As mentioned in <xref target="highlevel"/>, some GRASP operations
> might be
> performed across an administrative domain boundary by mutual
> agreement, without the
> benefit of an ACP. Such operations
> MUST be confined to a separate instance of GRASP with its own copy
> of all GRASP
> data structures. Messages MUST be authenticated and encryption MUST
> be used.
> <!-- TLS <xref target="RFC5246"/> and DTLS <xref target="RFC6347"/>
> based on a Public Key Infrastructure (PKI)
> <xref target="RFC5280"/> are RECOMMENDED for this purpose.-->
> Further details may be specified in future documents.
> </t></section>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
