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] Fwd: I-D Action: draft-ietf-opsec-probe-attribution-01.txt

[Andrew S2]

Many thanks to the authors for this draft, and the updates in the latest 
version, it's a great topic for this group to be working on. I think that 
standardising the suggestions on out-of-band attribution would be really 
useful. While I'm not too familiar with the situations mentioned in Section 5 
where out-of-band attribution will not work, I think there are sufficient 
issues with in-band attribution that it would be better to focus this draft on 
the out-of-band mechanisms.

In a little more detail:
* The suggestions on Out-of-Band Probe Attribution in Section 3 are easy to 
implement, lightweight suggestions that are similar to how we attribute our 
scanning at NCSC (UK National Cyber Security Centre). We scan for 
vulnerabilities across internet-connected systems in the UK and publish 
information on our scanning 
(https://www.ncsc.gov.uk/information/ncsc-scanning-information), providing the 
address of this webpage in reverse DNS, as the draft suggests. Standardising a 
.well-known URI is helpful, especially as it is in some sense capturing 
existing best current practice in this space.
* For Section 4, on In-band Probe Attribution, there are a couple of risks:
* As mentioned at the end of the section (and discussed on this list), 
there is a good chance that firewalls or middleboxes drop (or otherwise do 
something unexpected with) these unusual looking packets, compromising the 
scan. If following this document compromises the results of the scan, then I 
think it's unlikely that scanners will choose to add this information.
* Providing this information in the packet payloads would provide an 
easy way for a system to automatically block all scanning that complies with 
this document. This would provide little benefit to the system owner as it 
would only allow systems to block benign scanning that is compliant with this 
document. It would also reduce the amount of information available to 
researchers, making their scans less representative. It could prove 
particularly detrimental if systems make uninformed decisions to (attempt to) 
block all scanning by dropping packets that include this information. 

I hope these comments are helpful, thanks again to the authors for putting this 
useful document together.

Thanks,
Andy

-Original Message-
From: OPSEC  On Behalf Of Justin Iurman
Sent: 05 March 2023 12:47
To: opsec WG 
Cc: draft-ietf-opsec-probe-attribut...@ietf.org
Subject: [OPSEC] Fwd: I-D Action: draft-ietf-opsec-probe-attribution-01.txt

Hello,

This version addresses most of the comments received by Jen, Prapanch and 
Warren (thanks again for your reviews!). The diff is [1].

@Jen: with Éric, we finally decided that it might be better not to use 
normative language since this document is informational. Also, regarding your 
comment about DNS, we just wanted to make sure that you were talking about a 
TXT record where the value might "authenticate" the probes. Is it what you had 
in mind? If so, this is indeed a good idea, but we might need to define a new 
value/keyword for that, which might overcomplicate the document. Thoughts?

Thanks,
Justin

 Forwarded Message 
Subject: [OPSEC] I-D Action: draft-ietf-opsec-probe-attribution-01.txt
Date: Sun, 05 Mar 2023 04:21:30 -0800
From: internet-dra...@ietf.org
Reply-To: opsec@ietf.org
To: i-d-annou...@ietf.org
CC: opsec@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Operational Security Capabilities for 
IP Network Infrastructure WG of the IETF.

 Title   : Attribution of Internet Probes
 Authors : Éric Vyncke
   Benoît Donnet
   Justin Iurman
   Filename: draft-ietf-opsec-probe-attribution-01.txt
   Pages   : 9
   Date: 2023-03-05

Abstract:
Active measurements at Internet-scale can target either collaborating
parties or non-collaborating ones.  Sometimes these measurements are
viewed as unwelcome or aggressive.  This document proposes some
simple techniques allowing any party or organization to understand
what this unsolicited packet is, what is its purpose, and more
importantly who to contact.

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