Re: [OPSEC] OpSec@IETF117: Meeting minutes

[Arnaud Taddei]

Hi Jen, thank you to recognize I am just trying to be a good citizen here and 
to learn and understand.

And I did learn a few things in this email thread (tx Tom (1))

Irt “For example, I'm absolutely incapable of typing and listening at the same 
time... »

I agree, and I wish I could have the same model as here to have somebody takes 
note (thank you Henk) when I chair in other meetings in another SDO.

But I don’t and indeed it is a torture to chair AND take notes AND write the 
minutes (and I mean real formal ones).

Lucky you here.

Thank you for the updates, all good, keep doing.

Best Regards

PS

(1) @Tom on webmail formatting issue, agree, I more and more regret my VT100 
and pine as a brave IMAP client

From: Jen Linkova 
Date: Wednesday, 9 August 2023 at 18:08
To: Arnaud Taddei 
Cc: opsec WG , OpSec Chairs 
Subject: Re: [OPSEC] OpSec@IETF117: Meeting minutes
Hi Arnaud,

First of all, thank you for reading the minutes and providing
corrections and feedback ;)

On Tue, Aug 8, 2023 at 1:58 AM Arnaud Taddei  wrote:
> As I am still learning the IETF, I am a bit surprised. If ‘minutes’ mean ‘a 
> script of what was said on the mic’ then this is ok. But as chair in another 
> world, I have other expectations if these mean minutes:
>
> The minimum I expect is what is the decision made for each point in clear 
> text, something like:
> “the group decides X” | “the group adopts Y” | “the group doesn’t adopt Z but 
> recommends W as a way forward”

In general, you are right. The minutes are not expected to be a
detailed transcript, more like a summary of important points.
In the case of this particular session, I do not think any decisions
were actually made. I've updated the minutes to make it explicit
what's expected for the first two presentations.

> Actually the quote: “in the EU there is big DORA, capability of the EU to do 
> pentesting, maybe look at that if that is "adding water to your mill »
>
> This quote is attributed to Fernando but it was actually me 

That's exactly why I asked the group to read the minutes. Remember
that at the IETF we do not have professional stenographers. The
minutes are taken by volunteers, who are also participating in the
discussion.
For example, I'm absolutely incapable of typing and listening at the
same time...

> I would prefer it to be amended a bit as right now it doesn’t translate right 
> (and I can’t listen the replay right now):
>
>i.  “in 
> the EU there is the big DORA regulation which gives the EU the capability to 
> do pentesting using its TIBER-EU model, maybe [Fernando] look at that if that 
> is "adding water to your mill »

Done. PTAL and let me know if any changes are needed.

> From: OPSEC  on behalf of Jen Linkova 
> 
> Date: Tuesday, 8 August 2023 at 10:36
> To: opsec WG 
> Cc: OpSec Chairs 
> Subject: [OPSEC] OpSec@IETF117: Meeting minutes
>
> Hello,
>
> The meeting minutes from the IETF117 OpSec session have been published:
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://datatracker.ietf.org/meeting/117/materials/minutes-117-opsec-202307272230%26source%3Dgmail-imap%26ust%3D169208860700%26usg%3DAOvVaw3WLg34HD6PvFII0gWatbkL=gmail-imap=169220209100=AOvVaw0_A0LsqsEL_dzcsaSl9zT0
>
> Many thanks to Henk for taking them!
>
> If you said smth during the session pls check the minutes and ensure
> that your comment was captured correctly.
> Please let the chairs know if you think the minutes need to be amended.
>
> --
> Jen and Ron
>
> ___
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/opsec%26source%3Dgmail-imap%26ust%3D169208860700%26usg%3DAOvVaw0Jb5iIuq8s4InY6GGjn8cO=gmail-imap=169220209100=AOvVaw3x_J9bz6LjrYhhe0lbcXwq
>
>
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.



--
SY, Jen Linkova aka Furry

-- 
This electronic communication and the information and any files transmitted 
wi

Re: [OPSEC] OpSec@IETF117: Meeting minutes

[Arnaud Taddei]

Hmm, ok just to keep my comment in the box it was intended.

I am learning the IETF so thank you for the feedback. My point was super down 
on earth and selfish.

Like many my time is limited. When I receive a ‘minute’, in order to save time, 
I like to short cut a long read to reach out to the conclusions and be able to 
read a clear status.

As I couldn’t find it, I asked.

If this is not in the culture of the IETF, be it.

I was not debating on how consensus is built here or what not so lets not open 
this new box.

From: Gert Doering 
Date: Wednesday, 9 August 2023 at 13:27
To: tom petch 
Cc: Arnaud Taddei , Jen Linkova 
, opsec WG , OpSec Chairs 

Subject: Re: [OPSEC] OpSec@IETF117: Meeting minutes
Hi,

On Wed, Aug 09, 2023 at 10:35:10AM +, tom petch wrote:
> The Chairs may judge that support from six implementers weighs more
> than opposition from ten operators:-)  Such is the IETF.

Not sure if this was meant as a random example of why judging consensus
can be complicated at times - but as written, it does reflect quite well
on why operators feel that spending their time on IETF lists is a lost
cause...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] OpSec@IETF117: Meeting minutes

[Arnaud Taddei]

Thank you Jen,

Quick comments from a train in Germany


  1.  As I am still learning the IETF, I am a bit surprised. If ‘minutes’ mean 
‘a script of what was said on the mic’ then this is ok. But as chair in another 
world, I have other expectations if these mean minutes:
 *   The minimum I expect is what is the decision made for each point in 
clear text, something like:
 *   “the group decides X” | “the group adopts Y” | “the group doesn’t 
adopt Z but recommends W as a way forward”


  1.  Actually the quote: “in the EU there is big DORA, capability of the EU to 
do pentesting, maybe look at that if that is "adding water to your mill »
 *   This quote is attributed to Fernando but it was actually me 
 *   I would prefer it to be amended a bit as right now it doesn’t 
translate right (and I can’t listen the replay right now):

   i.  “in the 
EU there is the big DORA regulation which gives the EU the capability to do 
pentesting using its TIBER-EU model, maybe [Fernando] look at that if that is 
"adding water to your mill »

Hope this helps

Best Regards

From: OPSEC  on behalf of Jen Linkova 

Date: Tuesday, 8 August 2023 at 10:36
To: opsec WG 
Cc: OpSec Chairs 
Subject: [OPSEC] OpSec@IETF117: Meeting minutes
Hello,

The meeting minutes from the IETF117 OpSec session have been published:
https://www.google.com/url?q=https://datatracker.ietf.org/meeting/117/materials/minutes-117-opsec-202307272230=gmail-imap=169208860700=AOvVaw3WLg34HD6PvFII0gWatbkL

Many thanks to Henk for taking them!

If you said smth during the session pls check the minutes and ensure
that your comment was captured correctly.
Please let the chairs know if you think the minutes need to be amended.

--
Jen and Ron

___
OPSEC mailing list
OPSEC@ietf.org
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/opsec=gmail-imap=169208860700=AOvVaw0Jb5iIuq8s4InY6GGjn8cO

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

[Arnaud Taddei]

Ok Eduard I recognise a bit of the epidermic reaction (after all I am half 
latin blood) and missed the telco context because I see the drama in enterprise 
context every single day!

Now ironically the example I took below was a telco!

But I buy your point … all good

> On 25 May 2023, at 07:58, Vasilenko Eduard 
>  wrote:
> 
> Hi Arnaud,
> It is a good point that Enterprises have much more serious attention to 
> security. But Telco is not so much paranoid about security.
> The last initiative in this WG is about “to push Telco to tolerate all EHs”. 
> The context of this discussion is more about Telco.
>  
> > The additional cost you can find ways to write them off
> In the majority of cases “No”. Because tests could not be free, support could 
> not be free either. Performance penalty may be close to Zero (only a small 
> loss of bandwidth) – depending on the EH type (maybe a 2x drop of performance 
> because of recirculation).
>  
> > the ‘additional cost’ and the ’security risk’ are not symmetric at all.
> Yes, it is an apple and orange comparison. But both exist, and both may be 
> discussed.
>  
> Ed/
> From: Arnaud Taddei [mailto:arnaud.taddei=40broadcom@dmarc.ietf.org] 
> Sent: Thursday, May 25, 2023 8:47 AM
> To: Vasilenko Eduard 
> Cc: Fernando Gont ; Manfredi (US), Albert E 
> ; IPv6 Operations ; 6man 
> ; opsec@ietf.org
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking 
> IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>  
> +1 just that the ‘additional cost’ and the ’security risk’ are not symmetric 
> at all.
>  
> The additional cost you can find ways to write them off
>  
> The security risk is much more damaging because it is a compliancy risk 
> (think DORA for the FSI in EU), a reputation risk that is now captured by 
> credit rating agencies, a revenue risk, a  stock rating agencies (your stock 
> will drop), insurance ratings, etc. and 1) it is getting substantial and 2) 
> it is even existential with a few examples that some organizations literally 
> lost e.g. an MNO of €1.3B and 30 years of existence (only survived by 1 
> backup link), etc
>  
> On 25 May 2023, at 07:21, Vasilenko Eduard 
>  <mailto:vasilenko.eduard=40huawei@dmarc.ietf.org>> wrote:
>  
> IMHO: Fernando comes here with a good example (EH DoS). Security is a good 
> reason to block EHs.
> But for business, every feature should be tested, supported, and somebody 
> should pay an additional performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It 
> depends on the organization type.
> Ed/
> -Original Message-
> From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf Of Arnaud Taddei
> Sent: Thursday, May 25, 2023 8:12 AM
> To: Fernando Gont mailto:fg...@si6networks.com>>
> Cc: Manfredi (US), Albert E  <mailto:albert.e.manfr...@boeing.com>>; IPv6 Operations  <mailto:v6...@ietf.org>>; 6man mailto:i...@ietf.org>>; 
> opsec@ietf.org <mailto:opsec@ietf.org>
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking 
> IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
> 
> Would like to support Fernando again, and not just because I have a Sony TV 
> too. 
> 
> Cybersecurity is in such a bad state that I can only plea for a sense of 
> realism and pragmatism vs dogmatism to get real solutions at hand to the 
> defenders practitioners
> 
> If not I will ask people here to consider spending a week in a Security 
> Operation Center when there is a Ransomware breaking up 
> 
> Fernando’s paper intentions will be appreciated by the defenders  
> 
> 
> 
> 
> On 25 May 2023, at 03:07, Fernando Gont  <mailto:fg...@si6networks.com>> wrote:
> 
> 
> 
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
> 
> -Original Message-
> From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf 
> Of Fernando Gont
> 
> Given the amount of things that get connected to the Net (smart bulbs, 
> refrigerators, etc.) -- and that will super-likely never receive security 
> updates, you may have to **rely on your own network**.
> 
> For instance, I wouldn't have my smart TV "defend itself".
> Agreed, "on your own network." >From the viewpoint of a household, whatever 
> network defense has to be behind that household's router, for it to be 
> credible, and preferably right in each host. Yeah, some IoT devices may not 
> be updated regularly.
> 
> So, that's why people block them at the edge.
> 
> (just the messenger)
> 
> 
> 
> 
> The ISP has to worry about protecting that ISP's own network. 
> 
> That's e.g. where RFC90

Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

[Arnaud Taddei]

+1 just that the ‘additional cost’ and the ’security risk’ are not symmetric at 
all.

The additional cost you can find ways to write them off

The security risk is much more damaging because it is a compliancy risk (think 
DORA for the FSI in EU), a reputation risk that is now captured by credit 
rating agencies, a revenue risk, a  stock rating agencies (your stock will 
drop), insurance ratings, etc. and 1) it is getting substantial and 2) it is 
even existential with a few examples that some organizations literally lost 
e.g. an MNO of €1.3B and 30 years of existence (only survived by 1 backup 
link), etc

> On 25 May 2023, at 07:21, Vasilenko Eduard 
>  wrote:
> 
> IMHO: Fernando comes here with a good example (EH DoS). Security is a good 
> reason to block EHs.
> But for business, every feature should be tested, supported, and somebody 
> should pay an additional performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It 
> depends on the organization type.
> Ed/
> -Original Message-
> From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf Of Arnaud Taddei
> Sent: Thursday, May 25, 2023 8:12 AM
> To: Fernando Gont mailto:fg...@si6networks.com>>
> Cc: Manfredi (US), Albert E  <mailto:albert.e.manfr...@boeing.com>>; IPv6 Operations  <mailto:v6...@ietf.org>>; 6man mailto:i...@ietf.org>>; 
> opsec@ietf.org <mailto:opsec@ietf.org>
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking 
> IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
> 
> Would like to support Fernando again, and not just because I have a Sony TV 
> too. 
> 
> Cybersecurity is in such a bad state that I can only plea for a sense of 
> realism and pragmatism vs dogmatism to get real solutions at hand to the 
> defenders practitioners
> 
> If not I will ask people here to consider spending a week in a Security 
> Operation Center when there is a Ransomware breaking up 
> 
> Fernando’s paper intentions will be appreciated by the defenders  
> 
> 
> 
>> On 25 May 2023, at 03:07, Fernando Gont  wrote:
>> 
>> 
>> 
>> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
>>> -Original Message-
>>> From: ipv6  On Behalf Of Fernando Gont
>>>> Given the amount of things that get connected to the Net (smart bulbs, 
>>>> refrigerators, etc.) -- and that will super-likely never receive security 
>>>> updates, you may have to **rely on your own network**.
>>>> 
>>>> For instance, I wouldn't have my smart TV "defend itself".
>>> Agreed, "on your own network." From the viewpoint of a household, whatever 
>>> network defense has to be behind that household's router, for it to be 
>>> credible, and preferably right in each host. Yeah, some IoT devices may not 
>>> be updated regularly.
>> 
>> So, that's why people block them at the edge.
>> 
>> (just the messenger)
>> 
>> 
>> 
>>> The ISP has to worry about protecting that ISP's own network. 
>> 
>> That's e.g. where RFC9098 comes in, with notes on why they are dropped in 
>> places other than the edge network.
>> 
>> 
>> 
>>> Households have to be responsible for protecting their household's 
>>> network. (And connected TVs do get regular software updates, as a 
>>> matter of fact.)
>> 
>> I guess it all depends on the TV? e.g., I for one I'm not planning to throw 
>> it out just because Sony decided to quit pushing updates (which were never 
>> automatic for my set).
>> 
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fg...@si6networks.com
>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>> 
>> ___
>> OPSEC mailing list
>> OPSEC@ietf.org
>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/ops=gmail-imap=168559690600=AOvVaw1SaRszq_Trn0SZdoxCGfAf
>> ec=gmail-imap=168558168100=AOvVaw2CR1KLp2V-YO9ZOvhw
>> rWtn
> 
> 
> --
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, c

Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

[Arnaud Taddei]

Would like to support Fernando again, and not just because I have a Sony TV 
too. 

Cybersecurity is in such a bad state that I can only plea for a sense of 
realism and pragmatism vs dogmatism to get real solutions at hand to the 
defenders practitioners

If not I will ask people here to consider spending a week in a Security 
Operation Center when there is a Ransomware breaking up 

Fernando’s paper intentions will be appreciated by the defenders  



> On 25 May 2023, at 03:07, Fernando Gont  wrote:
> 
> 
> 
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
>> -Original Message-
>> From: ipv6  On Behalf Of Fernando Gont
>>> Given the amount of things that get connected to the Net (smart bulbs, 
>>> refrigerators, etc.) -- and that will super-likely never receive security 
>>> updates, you may have to **rely on your own network**.
>>> 
>>> For instance, I wouldn't have my smart TV "defend itself".
>> Agreed, "on your own network." From the viewpoint of a household, whatever 
>> network defense has to be behind that household's router, for it to be 
>> credible, and preferably right in each host. Yeah, some IoT devices may not 
>> be updated regularly.
> 
> So, that's why people block them at the edge.
> 
> (just the messenger)
> 
> 
> 
>> The ISP has to worry about protecting that ISP's own network. 
> 
> That's e.g. where RFC9098 comes in, with notes on why they are dropped in 
> places other than the edge network.
> 
> 
> 
>> Households have to be responsible for protecting their household's network. 
>> (And connected TVs do get regular software updates, as a matter of fact.)
> 
> I guess it all depends on the TV? e.g., I for one I'm not planning to throw 
> it out just because Sony decided to quit pushing updates (which were never 
> automatic for my set).
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
> 
> ___
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/opsec=gmail-imap=168558168100=AOvVaw2CR1KLp2V-YO9ZOvhwrWtn


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] test

[Arnaud Taddei]

Delete



-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] [ECH-DEPLOY] GitHub is public

[Arnaud Taddei]

The work on draft-campling-ech-deployment-considerations 

 was moved under a GitHub project over the past 4 months

Whilst we are still learning GitHub and improving, as requested, we agreed to 
make it public at:  

https://github.com/echdeploy/draft-ech-deployment-considerations

Remember we are still new at GitHub, so, don’t hesitate to share best practices 

Best Regards
-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] Adoption Call: draft-gont-opsec-ipv6-addressing

[Arnaud Taddei]

Not sure where we are on this one, but I will re-iterate my support for the 3rd 
time (once in the meeting and 2 times on this list).


> On 2 May 2023, at 20:56, Dhruv Dhody  wrote:
> 
> Hi, 
> 
> I support adoption! 
> 
> Some Nits - 
> - Expand SLAAC
> - s/each prefix advertised advertised for address/each prefix advertised for 
> address/
> - add reference for Kubernetes and IPv6-enabled VPNs
> - s/since sunch IPv6 prefix/since such IPv6 prefix/
> - suggest using their instead of his/her
> 
> Thanks! 
> Dhruv
> 
> 
> 
> On Mon, Apr 10, 2023 at 5:52 PM Eric Vyncke (evyncke) 
> mailto:40cisco@dmarc.ietf.org>> 
> wrote:
>> Hello Fernando,
>> 
>> No problem at all of course, we all work to improve the security of the 
>> Internet (which is obviously IPv6 ;-) )
>> 
>> Cheers
>> 
>> -éric
>> 
>> On 10/04/2023, 09:28, "Fernando Gont" >  > >> wrote:
>> 
>> 
>> Hello, Eric,
>> 
>> 
>> On 8/4/23 02:13, Eric Vyncke (evyncke) wrote:
>> > May I suggest that this draft, at the bare minimum, has RFC 9099 (an
>> > OPSEC document) in its references list? Notably because the draft
>> > sections about network correlation is already addressed in RFC 9099
>> > section 2.6 and others.
>> 
>> 
>> This was my bad '' this )and other references) is in our TO-DO list for 
>> the next rev.
>> 
>> 
>> Thanks!
>> 
>> 
>> Fernando
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fg...@si6networks.com  
>> >
>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>> 
>> 
>> 
>> ___
>> OPSEC mailing list
>> OPSEC@ietf.org 
>> https://www.ietf.org/mailman/listinfo/opsec 
>> 
> ___
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/opsec=gmail-imap=168365866100=AOvVaw3uZA_tnNGFjWaR3jQY-UcI


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] Test

[Arnaud Taddei]

ignore


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] Operational Security Considerations and Encrypted Client Hello

[Arnaud Taddei]

Thank you Warren, we appreciate be given a chance to present.

Please note we issued revision -04 and plan a revision -05 by Monday 27th of 
March.
https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/
One question as we are working on the best way to make our Github public.

I observed that there is a ’tslwg’ Github entity which is hosting for example 
the ECH repo.

Is there an equivalent ‘opsecwg’ entity we should be using to host our repo and 
have all the magic links done (notifications, etc.) through this working group 
mailing list?

Sorry if this is a naive question. Trying to do the right things the right way.

Best

> Le 7 mars 2023 à 23:22, Warren Kumari  a écrit :
> 
> Hello WG!
> 
> I'd encourage the WG to review this document - it's relatively short, and is 
> an easy read.
> 
> ECH is likely to be a fairly active topic in the IETF, and has significant 
> Opsec implications. The document is on the OpSec agenda, and so having read 
> it before the meeting will be really helpful..
> 
> W
> 
> 
> 
> On Fri, Feb 17, 2023 at 8:15 AM, Andrew Campling 
> mailto:andrew.campling@419.consulting>> 
> wrote:
>> Hi Opsec wg
>> 
>> You may be aware that some of us have been looking at the potential impact 
>> of the deployment of Encrypted Client Hello (ECH), an extension to TLS1.3+.  
>> We are continuing to develop the draft, which is accessible at 
>> https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/.
>>   You will note that many of the issues that we have identified relate to 
>> various aspects of operational security in a variety of contexts.  
>> 
>>  
>> 
>> We have been encouraged to share the draft with the Opsec working group to 
>> see if there is interest in the topic within the group, hence this post.  I 
>> and at least one of my co-authors will be present in Yokohama for the IETF 
>> 116 meeting and will be happy to present the highlights of the draft if time 
>> is available on the wg agenda.  
>> 
>>  
>> 
>>  
>> 
>> Andrew 
>> 
>>  
>> 
>> ___ 
>> OPSEC mailing list 
>> OPSEC@ietf.org  
>> https://www.ietf.org/mailman/listinfo/opsec
>> 
> 
> 
> ___
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] Adoption call for draft-paine-smart-indicators-of-compromise

[Arnaud Taddei]

I would like too to support adoption of this document. IoCs are a fundamental 
element of the defenders and this is important work to keep developing. I will 
continue to review and contribute to this work.

Best, Arnaud

Envoyé de mon iPad
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec