Re: [domainrep] Charter going to the IESG

[Douglas Otis <[e-mail]>]

On 9/12/11 9:11 PM, Murray S. Kucherawy wrote:
> > -----Original Message----- From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Douglas Otis Sent:
> > Monday, September 12, 2011 5:27 PM To: [e-mail] Subject:
> > Re: [domainrep] Charter going to the IESG
> >
> > You are free to have an overly optimistic belief the lack of
> > replay control permitted by ignoring sender and recipient won't be
> > abused. Adding this "optimism" to the charter is still not wise nor
> > necessary for such experimentation.
>
>  Indeed, just as you are free to be overly (and singularly)
>  pessimistic about the potential of the concept.
>
>  Nothing about what I said is in the charter though, except that the
>  charter doesn't preclude the idea.
>
>  As Dave said, we are all aware that you have pet peeves with SPF and
>  DKIM, but there is clear consensus that the flaws you highlight ad
>  nauseam are at best corner cases that should not deter continued
>  advancement of this work or work on those protocols.

Murray,

Sorry for the trouble.  This is only to challenge erroneous statements 
made in the charter as it relates to Security.
,--
"Various mechanisms have been developed for associating a verified 
identifier with email content, such as with SPF (RFC4408) and DKIM 
(RFC4871). ... Given the recent adoption of domain name verification for 
email, by SPF and DKIM, the most obvious initial use case for reputation 
is for email."
'--

There are several Security problems with these two statements related to 
reputation that the Repute mailing list is unwilling to discuss.  There 
is no reason to make them in the charter, where simple removal would be 
a remedy.  Alternatively, this might suggest an experiment using DANE 
with outbound MTAs and there would also not be any Security concern 
wasting our time.

The Security aspects relate to a domain's inability to defend their 
reputation when based upon either IP address authorization or signed 
messages that exclude sending domains and intended recipients.  This has 
real DoS potential.

There is no way to know whether statistical exceptions are legitimate.  
The "at best corner cases" represents every message sent from this 
mailing list or any message sent using BCC, for example.  The same 
issues occur with shared outbound MTAs where every email potentially 
falls into easily exploitable "corner cases".  Defending this requires 
that recipients refuse all exceptions.

Email reputation is challenged to respond to the introduction of IPv6.  
Already the announced prefix space (ignoring the lower 64 bits) is more 
than 56,000 times the entire IPv4 address range and growing 
exponentially.  Perhaps the prefix space alone will soon start 
flattening out at about 340,000 times that of the entire IPv4 address space.

Deployment of IPv6 over IPv4 is problematic.  The current strategy is to 
use Dual-Stack Lite.
http://tools.ietf.org/html/rfc6333
http://tools.ietf.org/html/draft-bpw-pcp-nat-pmp-interworking-00
This moves CPE NAT to the ISP or enterprise tunnel over 192.0.0.0/29.

This change in Internet infrastructure demands deprecation of IPv4 
address based verifications, and replacement with secure end-to-end 
methods.  Neither is meet by SPF or DKIM.  There is little time to waste 
so we need to be smart and use the right tools.

-Doug