[ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.

[Hallam-Baker, Phillip]

Stephen has almost captured my issues here.

My point here is that since NOMAIL is not a MUST requirement we do not require the same level of design for deployment as for a feature that is a core requirement. In particular it is acceptable for us to specify a scheme which requires deployment of new DNS infrastructure for NOMAIL, this seems obvious to me as there are existing schemes which address this requirement.

I do want to solve NOMAIL, in fact I think that it is essential that we do so to close all possible avenues of attack, including the unsigned mail from nonexistent domain attack. However I am quite happy for expression of NOMAIL to require deployment of an XPTR capable DNS server.

I am proposing a scheme here which allows for a transition to a principled infrastructure in which NOMAIL like DKIM is supported as a first class entity. 


All I don't want to do is to discuss the details of NOMAIL implementation at this point. If we get the structure right they take about half an hour.

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Stephen Farrell
> Sent: Wednesday, June 06, 2007 10:45 AM
> To: Hector Santos
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] RE: I think we can punt the hard 
> stuff as out ofscope.
> 
> 
> Hector,
> 
> You are correct that there is no MUST NOT. But the fact that 
> we excised the MUST is significant. I interpret that as follows:
> 
> - Its ok for someone to develop a proposal for how nomail 
> could be included, so long as it doesn't get in the way of 
> the meeting the MUST & SHOULD requirements, which we do first 
> (that's sort-of what PHB suggested yesterday, I think);
> - its not ok to hold up work on the basis that nomail isn't included.
> 
> Later in your mail you seem to say that there was some 
> ambiguity when we decided the above. I totally disagree with 
> that - the mail archive is very clear.
> 
> Regards,
> Stephen.
> 
> Hector Santos wrote:
> > Grown up?
> > 
> > Stephen,
> > 
> > I don't think the whatever the STRAWPOLL was based on, it 
> was VERY clear.
> > 
> > Going back, I can now see that it appears this was for the 
> > REQUIREMENTS not for a SSP proposal itself.
> > 
> > The issue came about MUST NOT REQUIRE THAT SSP LOOKUP BE FIRST.
> > 
> > We debated this back and forth as well and it was made clear that 
> > requirement does not MEAN proposals can not include such logic.
> > 
> > It does not SAY that a "SSP" proposal MUST NOT include a 
> NOMAIL provision.
> > 
> > You are making it sound that it MUST NOT include a NOMAIL provision 
> > which is 100% uncategorily wrong.
> > 
> > And now it is clear the issue was not poised correctly. 
> Based on your 
> > footnotes below, the question was brought up because some one felt
> > (incorrectly) that it was a specific form of "strict."
> > 
> >     5.3 (2): IIRC we've identified "never send mail" as a special
> >     case of "strict", and then just not sending mail, let
> >     alone signing it. IMO you can delete this point.
> > 
> > if this is basis of the issue, it was INCORRECTLY though out.
> > 
> > There is no relationship with STRICT and NOMAIL.  STRICT is 
> related to 
> > exclusive SIGNING or NO SIGNING which is different than NO MAIL.
> > 
> > The point is simple:
> > 
> > It doesn't make sense to REMOVE a NOMAIL policy.  If a 
> domain is based 
> > forged with fake signatures, why should a VERIFIER be left with the 
> > overhead of processing FAILED signature without any 
> recourse of simply 
> > DELETING this MAIL?
> > 
> > If the DOMAIN says, there SHOULD BE NO MAIL based on this 
> DOMAIN, then 
> > that is a CLEAR indicator of abuse which the verifier 
> should delete. 
> > It protects the verifier and it protects the domain.
> > 
> > We can't say NO SIGNATURE is equivalent to NO MAIL, but that is not 
> > enough to handle this type of abusive mail.
> > 
> > If I receive an email with an domain such as:
> > 
> >       secured.cs.tcd.de
> > 
> > and it is NOT signed, the DOMAIN can clearly TELL me 
> whether this is 
> > expected or not:
> > 
> >    1  - This message MUST NEVER be signed
> > 
> >    2  - This message MUST ALWAYS be signed
> > 
> >    3  - This message MAY be signed
> > 
> >    4  - This messages MUST never have secure.cs.tcd.de because
> >         we DON'T send mail with this this domain.
> > 
> > With 1 and 3, the message is acceptable, with 2 and 4, I 
> can mark this 
> > message is bad or maybe get rid of this junk.
> > 
> > The #4 is important because this is a HIGH POTENTIAL 
> transaction once 
> > domains begin to turn on there DKIM system. There will be many 
> > currently exploited domains that will come in with no 
> signatures and 
> > unless they all do #2, #4 is the only way to cleanly with NO FALSE 
> > positives, to get rid of this abuse.
> > 
> > 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>