[dmarc-ietf] Rolling out the experiment

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Sun, 31 March 2019 21:07 UTC

Return-Path: <btv1==99374fdb37c==fosterd@bayviewphysicians.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382D11200D8 for <dmarc@ietfa.amsl.com>; Sun, 31 Mar 2019 14:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV8pHl-bam5e for <dmarc@ietfa.amsl.com>; Sun, 31 Mar 2019 14:07:19 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862F9120003 for <dmarc@ietf.org>; Sun, 31 Mar 2019 14:07:19 -0700 (PDT)
X-ASG-Debug-ID: 1554066437-0990574bec20f300001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id XsIatxEJeH9i2HN0 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sun, 31 Mar 2019 17:07:17 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-ASG-Whitelist: Client
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=HWU11aHZlgdBHckv+l1SEMgIx1w04ZVdXvwl1JT3VHI=; b=BCBmfOui1q7cTARm8E+LWxM6Z0cGCtRUy+6aMgGI9j1cx+gyMq3J3OayX8YpyM6/E iE4lMNCR2IYT8aHz6VzvQhzq3TL7D1e1l+0Ai7xytQhCenGc9mf6QaTekrKfbnMWx G3UEL3U7nh/84mNcTzaXcs3KSxVQE3pW7vLICsBxs=
Received: by webmail.bayviewphysicians.com via HTTP; Sun, 31 Mar 2019 17:07:09 -0400
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: <dmarc@ietf.org>
Date: Sun, 31 Mar 2019 17:07:09 -0400
X-ASG-Orig-Subj: [dmarc-ietf] Rolling out the experiment
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <e1098e14b0b54c79b9f6191eb4afa2fd@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=16d054cb8f684ecfb20d8c769c579647
X-Originating-IP: [192.168.1.239]
X-Exim-Id: e1098e14b0b54c79b9f6191eb4afa2fd
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1554066437
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 19057
X-Barracuda-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wTGXDC8Ggc8hgZWp2zyzzaG-M50>
Subject: [dmarc-ietf] Rolling out the experiment
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2019 21:07:22 -0000

Based on my reading of your draft, the testing process for non-existent domains is as follows:
  	Any DMARC policies for non-existent domains must be removed, so that the recipient system can look upward to the PSD DMARC. 	SPF and ASDP polices can still be published for non-existent domains, because a domain is non-existent only when it lacks A, AAAA, and MX records.  SPF and ADSP are TXT records, so they do not affect the evaluation.  What I do not understand is how a device determines that a particular domain has no A, AAAA, or MX records. 	Assuming that #2 iis valid, the test can proceed with no loss of current protections.  SPF and ADSP policies can be used to block a fraudulent message from a non-existent domain.   The behavior varies by device capability.    	 		A non-DMARC device would stop after blocking the message because of SPF or ADSP policy violation.   		An organization-DMARC device would look for a DMARC policy and fail, so no feedback would be sent.  It would still block the message based on SPF and DMARC policy violations.    		A PSD-DMARC device could block the message by either of two methods: 		 			It detects the domain as non-existent, and looks immediately for a PSD-DMARC policy. 			It blocks the message based on SPF or DMARC, then looks for feedback instructions, following the tree upward until it finds a PSD DMARC policy with feedback instructions. 		

 SPF is widely deployed, so dropping SPF policies will affect recipients not participating in the test.    That is why I am alarmed.
  
 I do not understand why that should be necessary, but I suppose that the answer hangs on the mechanism for detecting non-existent domains in a manner compliant with section 2.6 
  
 Doug Foster
  
  
  
  

----------------------------------------
 From: "Ian Levy" <ian.levy@ncsc.gov.uk>
Sent: Sunday, March 31, 2019 3:07 PM
To: "fosterd@bayviewphysicians.com" <fosterd@bayviewphysicians.com>om>, "ScottKitterman" <sklist@kitterman.com>om>, "IETF DMARC WG" <dmarc@ietf.org>rg>, "Ian Levy" <ian.levy=40ncsc.gov.uk@dmarc.ietf.org>
Subject: Re: [dmarc-ietf] Working group next steps   
   The existing defences aren't 100% even before the evil kludge we've put up for non existent subdomains, which certainly is not working everywhere. The PSD draft, when implemented, will help scale existing defences to make evolution of criminal behaviour harder and do it in a standardised way so that it's more likely to be consistently implemented.  That's worth us collectively doing some work and me taking some risk to help early testing. 

  
 Nothing is 100% in security. Except possibly the existence of a preponderance of marketing hype :-). 
  
 Ta. 
  
 I. 
  
  -
 Dr Ian Levy
 Technical Director
 National Cyber Security Centre
 ian@ncsc.gov.uk
  
 (I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)

----------------------------------------
 From: dmarc <dmarc-bounces@ietf.org> on behalf of Douglas E. Foster <fosterd@bayviewphysicians.com>
Sent: Sunday, March 31, 2019 7:31 pm
To: Scott Kitterman; IETF DMARC WG; Ian Levy
Subject: Re: [dmarc-ietf] Working group next steps      

 Certainly not.   
  
 You cannot drop existing defenses until the new standard is 100% deployed on the Internet, which means probably never.    Your experimental implementation will need to prioritize the new test over the SPF test, to prove that it is working and to show that it is good at intercepting any subdomains that have been newly imagined by the attackers
  
 To speed up the deployment process for existing or new standards, IETF would meed to embrace the idea of defining required features of a spam filter.
  
 Doug Fosterd
  

----------------------------------------
 From: "Ian Levy" <ian.levy=40ncsc.gov.uk@dmarc.ietf.org>
Sent: Sunday, March 31, 2019 6:18 AM
To: "Scott Kitterman" <sklist@kitterman.com>om>, "IETF DMARC WG" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Working group next steps    
 >> I'll also offer gov.uk as an experimental ground (within reason!).

> Excellent. I've listed it in the experimental registry at psddmarc.org..
> Since you already had a live DMARC record for that domain, people can experiment with this now.

I guess at some point we'll have to stop generating SPF and DMARC records for the non-existent subdomains of gov.uk so we can test the new stuff properly. When we're at that point, let me know.

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk

Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk

(I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk