OpSec Working Group - IETF 116

Thu, March 30, 15:00 - 16:00 GMT+9/06:00 - 07:00 UTC  
Chairs: Jen Linkova, Ron Bonica

Minute taker: Kirsty Paine

Chat Room: https://zulip.ietf.org/#narrow/stream/opsec

Meetecho:
https://meetings.conf.meetecho.com/ietf116/?group=opsec&short=&item=1

## Introduction and Document Status, Chair   {#introduction-and-document-status-chair}

Jen chairing solo today; Kirsty taking minutes.

## Implications of IPv6 Addressing on Security Operations, draft-gont-opsec-ipv6-addressing, Fernando Gont, 30 min   {#implications-of-ipv6-addressing-on-security-operations-draft-gont-opsec-ipv6-addressing-fernando-gont-30-min}

[draft-gont-opsec-ipv6-addressing][1]

[Slides][2] presented.

Jen Linkova: Thank you for presenting. Some of this is not a new
problem, can you distil the parts that are specific to v4, and the parts
that are the same as before and just apply here too?  
Fernando: For people who don't follow the v6 topic closely, they may not
know these "older problems". Unfortunate turn of events, but from a
pragmatic perspective, we have what we have.   
Jen: You might want to mention NAT64 (IPv4<>IPv6 addresses) in the
correlation section.  
Diego Lopez: Glad to see what was being presented. This work has been
going on for a long time, to my colleagues working in IPv6 deployment
and practices, we lack a best practice in security. As long as my
bandwidth allows, I would want to help.  
Jen Linkova: For the problem of adding IPv6 addresses to ACLs, v6ops is
discussing a draft of delegating /64 per host - that would make the ACL
creation easier.  
Diego Lopez: I like this more pragmatic approach though.  
Christopher Wood: You talk about different security practices that work,
and I'm asking what policies they are and how they protect it. Should we
be looking higher up the stack to provide that? I'm not an expert in
networking or anything really. The trend I see is enforcing security
using identity, which is usually higher up the stack. I'm not sure if
this how things work today, or if we should be solving things in a
fundamentally different way.  
Fernando: Thinking of a concept of defence-in-depth; it's not one thing
or the other. I have things to block well-known scanners, like Shodan
and censys, but that's not my whole security strategy. Of course, it's a
part. It's typically used as a part.  
Christopher Wood: Not saying it's not valuable work, don't get me wrong.
I agree with the two examples given, just asking the philosophical
question. I agree I want to block that scanner that's continually
hitting my service, influencing my metrics. In my ideal world, limiting
our reliance on IP addresses seems like the right direction to move it.
This work seems like it further encourages us to ossify IP addresses.  
Fernando: Another example. I don't want some devices to be accessible
even at the application layer, I just want to block them. It's just a
tool. Sometimes it's useful, sometimes it's not.  
Arnaud Taddei: Thank you for this work. I have two streams of comments,
the first is to support this work and Diego's comments, and to discuss
with Chris offline on his ideal world - my head is busy. In operational
security, we are missing specialists - 3.4 million specialists. Our
number one priority is contra ransomware, and whole companies lose their
30 years of business except for one single link. There were tonnes of
examples that I could add to Fernando's point. To give people the
urgency, we need the tools today and now. Today the state of opsec is
really bad. We have a lack of all sorts of things, this is just to
minimise the gap of what we have right now. Second thing, in ITU-T,
there is a technical report, SRv6. Same intention, there was a liaision
statement from SG17, if the work item is established here, we should let
them know.

Poll: 13 raised hands to adopt the item, 0 against. To be confirmed
on-list.

*   Encrypted Client Hello (ECH) Deployment considerations,
    draft-campling-ech-deployment-considerations, Andrew Campling, 20
    min

[Slides][3] presented.

Daniel Kahn Gillmor (ACLU): I'm unaware of any regimes that mandate SNI
filtering. But any SNI-based filtering would be ineffective. This is not
reliable. Not what happens when the signal goes away, if this draft
doesn't recognise that the current signal is unreliable.  
Andrew: the current draft does acknowledge that it's unreliable and how
you can validate SNI.  
DKG: It's the same thing for Fernando's draft.   
Andrew: The SNI is not the only IoC, it's the most important one.  
Arnaud Taddei: Let's forget the SNI for a minute. Nothing is reliable,
that's why people created zero trust. But SNI is just one of these
elements that can be tricked, changed, and so on. That's why it's one of
many things. The SNI is used worldwide today, it's one of the only
things that people can use. That's why the draft says we have to say
check. That's why on the enterprise we have to do selective decrypt,
that's selected on the SNI. If that's removed, I don't know how you do
this work.  
Christopher Wood: Where you don't have DNS filtering, and people are
only focusing on ECH... If there's any data that tells you how common
this environment is, that would be interesting. Otherwise, just filter
at the DNS layer. I don't know how big the world is where you can't
filter at the URL layer, or the DNS layer.  
Andrew: Yes, we're adding text on that specific point.  
Diego Lopez: DKG said what I was going to say. Similar to IPv6. It's
illustrating to those who are not savvy.

Adoption to be discussed on the list.



[1]: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/
[2]: https://datatracker.ietf.org/doc/slides-116-opsec-implications-of-ipv6-addressing-on-security-operations/
[3]: https://datatracker.ietf.org/doc/slides-116-opsec-encrypted-client-hello-deployment-considerations/