[ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.
pbaker at verisign.com
Wed Jun 6 11:51:22 PDT 2007
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.
> 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.
> 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
More information about the ietf-dkim