Re: [dmarc-ietf] Draft DMARC working group charter

[Pete Resnick]

On 7/5/14 11:09 PM, Hector Santos wrote:

On 7/5/2014 3:20 PM, Pete Resnick wrote:


The current text is now in front of the IESG for internal review.
Assuming we approve it for external review on Thursday, you will see a
announcement soliciting comments. A simple comment, with specific
suggested textual changes, would be welcomed.


   Rewrites of 5322.From headers are a serious security problem
   that will damage the efficacy and purpose of mail security
   goals of the DMARC protocol and also set a dangerous precedence
   for the mail framework as a whole.  It is therefore out of scope.
   The WG will not justify nor promote rewrite proposals and will
   consider them as security problem to mitigate in the security
   section.


Your suggestion will be taken into consideration. I will certainly 
forward it to the IESG during external review if you don't.


(I should say that I *personally* don't think it's necessary to make 
such a strong statement, as I don't think it's going to change the 
outcome. So if others think that the statement needs strengthening along 
these lines, do speak up at external review time. Either way, I will 
make the IESG aware of the comment.)


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

Re: [dmarc-ietf] Draft DMARC working group charter

[Hector Santos]

On 7/5/2014 3:20 PM, Pete Resnick wrote:


The current text is now in front of the IESG for internal review.
Assuming we approve it for external review on Thursday, you will see a
announcement soliciting comments. A simple comment, with specific
suggested textual changes, would be welcomed.


   Rewrites of 5322.From headers are a serious security problem
   that will damage the efficacy and purpose of mail security
   goals of the DMARC protocol and also set a dangerous precedence
   for the mail framework as a whole.  It is therefore out of scope.
   The WG will not justify nor promote rewrite proposals and will
   consider them as security problem to mitigate in the security
   section.

Thanks

--
HLS


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

Re: [dmarc-ietf] Draft DMARC working group charter

[Pete Resnick]

On 7/5/14 7:59 PM, Hector Santos wrote:

On 7/3/2014 11:04 PM, Pete Resnick wrote:


"As the working group develops solutions to deal with indirect mail
flows, it will seek to maintain the end-to-end nature of existing
identifier fields in mail, in particular avoiding solutions that
require rewriting of originator fields."


It is simply important that when solutions get discussed, if a
proposal is made for one that involves rewriting originator fields,
those of us who feel that it is a show stopper need to clearly,
concisely, and professionally lay out the arguments for why doing so
is very problematic.


And there is where my concern lies.

This puts an unnecessary heavy burden on proving why...


Well, let's be clear: The current charter text says that the WG is going 
to avoid such solutions. So the *initial* "burden of proof" (so to 
speak) is going to be on those proposing a solution that rewrites 
originator fields. It is only once they make a case that it *is* 
reasonable to do such a thing, both at a technical level and as a matter 
of doing something against the charter, that folks might be asked to 
explain why it is still problematic in light of the new information 
brought forth by the proponents.


At least that's the way I read the current charter text.

We don't need to waste time in waiting for the obviously bad thing to 
go wrong before action is taken and with the IETF appeal process, its 
generally too late.


Many tend to forget that the appeal process does not start with an 
appeal to the IESG at Last Call or later. In fact, it doesn't start with 
an "appeal" at all. If anyone disagrees with a WG decision, whether a 
strictly technical objection or because the WG simply failed to properly 
consider an alternative view, that should get brought to the chair 
immediately. No waiting.


I am absolutely worried that indirect endorsement or redesign 
considerations for rewrites...


I don't see this "indirect endorsement or redesign considerations for 
rewrites" in the charter text.



So do I understand you to say that you think the text is not strong
enough?


Probably. Whats stronger than strong?  Outlawed?


The current text is now in front of the IESG for internal review. 
Assuming we approve it for external review on Thursday, you will see a 
announcement soliciting comments. A simple comment, with specific 
suggested textual changes, would be welcomed.


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

Re: [dmarc-ietf] Draft DMARC working group charter

[Hector Santos]

On 7/3/2014 11:04 PM, Pete Resnick wrote:


"As the working group develops solutions to deal with indirect mail
flows, it will seek to maintain the end-to-end nature of existing
identifier fields in mail, in particular avoiding solutions that
require rewriting of originator fields."



It is simply important that when solutions get discussed, if a
proposal is made for one that involves rewriting originator fields,
those of us who feel that it is a show stopper need to clearly,
concisely, and professionally lay out the arguments for why doing so
is very problematic.


And there is where my concern lies.

This puts an unnecessary heavy burden on proving why it was a long 
time ethical engineering taboo to tamper with the "From" field of any 
communications I/O in the annals of telecomputing, especially for the 
purpose of breaking and getting around a new layer of mail security. 
 The mail comm I/O infrastructure was never designed for it and for 
long time historical good, legitimate and legal reasons.


Do we need to go into a justification why 5322.From is the only 
required header to be hash bound to the DKIM signature?  Thus making 
it technically impossible of disassociating the purported author 
identity from the signer identity?


Maybe we should do a DKIM errata to relax the 5322.From header hashing 
requirement? Or do so with the DKIM v=2 talks?


The DKIM threat analysis work considered the condition where a bad guy 
can purposely invalidate a signature and since DKIM mandates a MUST to 
ignore the signature as it was never signed, it was still possible to 
still protect the domain using a DKIM signature author domain 
authorization protocol policy. This was not something the signer 
domain could handle because it was invalidated. While the rewrite idea 
opens the door for good intention guys to bypass downlink DKIM related 
security checks, it opens the door on the bad guys to do the same thing.



A good chair should recognize the technical
issues and will not call consensus if they are not satisfactorily
addressed. Appeals are for when things go wrong, not when we're
worried about things going wrong.


Engineering training and experiences gives us the ethical and 
engineering insights to know what is right and wrong.  We don't need 
to waste time in waiting for the obviously bad thing to go wrong 
before action is taken and with the IETF appeal process, its generally 
too late. I am absolutely worried that indirect endorsement or 
redesign considerations for rewrites will not only seriously damage 
DKIM and any policy work, it can have a drastic impact on decades of 
integrated mail design expectations across the board.



[...]As a core mail principle, it MUST NEVER be valid to tamper with
5322.From, especially as a way to bypass a security protocol.

The entire idea needs to be out of scope.


So do I understand you to say that you think the text is not strong
enough?


Probably. Whats stronger than strong?  Outlawed?

By specifically highlighting it in the charter text as you suggest, it 
is presented as the specific alternative solution to the DKIM 
signature identity authentication/authorization problem.


It is not an alternative solution in the same way a double From wasn't 
a alternative to bypassing DKIM security checks.  It should to be 
presented among the potential serious security problems and not as the 
"path of least resistance" alternative to get around a mail security 
wall.


Thanks

--
HLS


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

Re: [dmarc-ietf] Draft DMARC working group charter

[Stephen J. Turnbull]

Dave Crocker writes:

 > The sub-thread is about discerning the organizational domain (OD).
 > It's not about authentication and it's not about 'responsibility'.
 > Those are separate, higher-level topics.

I thought the subthread was about why *we* aren't going to talk about
discerning an OD beyond saying that once you've done that, you use it
in the relaxed alignment algorithm.  That's our use case, and ISTM
that's all we really have to offer to the DBOUND debate.

 > the DMARC wg can and should play a role in that other activity, but
 > we need to be careful that we don't confuse 'play a role' with
 > 'work on the solution', nevermind 'try to deliver a solution'.

I strongly agree both with playing a role and with your caveats.  I
think that's a consensus (at least from the posts so far).

 > Hmmm... I suppose we should also cite adding the mechanism into the
 > DMARC spec, if there is a standard developed in time?

Doesn't the sentence from the proposed charter:

However the working group can consider extending the base DMARC
specification to accommodate such a standard, should it be
developed during the life of this working group.

which is referring to OD, express that well enough?  You could move it
to a bullet point, I guess.

 > It's probably worth some redundancy:  Finding the OD in a domain name is
 > a mechanical process that has nothing to do with email, responsibility
 > or the like.

We probably "must" define it in terms of a mechanical process, but we
should recognize that we're probably screwing some users when we do.
It forces some domains into using adkim=s and/or aspf=s when they'd
rather not (IIUC, the customers of com.uk are an example for some
definitions of OD).  It is not clear to me that we will be able to
serve all such needs simultaneously.

 > (Given the range of functionality suggestions already made for
 > finding the OD, the question of how it will get used seems to be
 > more complicated than one might naturally have guessed.)

My profession is economics: it's very natural for me to think in terms
of the variety of human ends being addressed rather than a collection
of technical proposals, and to therefore expect complexity.

What surprises me is how often a rather simple technical proposal
generates consensus because cooperation offers sufficient advantages
to all the individuals to offset the costs of overcoming human and
organizational inertia.

Unfortunately, I don't think "organizational domain" is susceptible to
that kind of solution ... but I'll keep hoping.

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