Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve,

After reading the recent mails it seems that I should have submitted the
draft on the gsoc website.
I shall do the same immediately :)


Aditya



On Wed, Mar 16, 2016 at 10:04 PM, Aditya Divekar 
wrote:

> Hi Steve,
>
> I went ahead and drafted a rough proposal as you advised.
> I've included the schedule with the deadlines in the proposal, and
> mentioned the dates with the purpose of giving an approximate idea of how
> the project will be executed.
> The link to the proposal is attached below, and it would be great if you
> could put in your comments in the proposal regarding any opinion that you
> have of it.
>
> Proposal
> 
>
>
> I haven't submitted this docs link in the summer of code page yet, as I
> would like to get your review first regarding it.
>
> Also,
>
>>
>> I'm going to be out of circulation for another 36 hours or so.  I did
>> want to comment on your new milestones but have other things to take
>> care of so it will have to wait.
>>
>>
> Yes, we could discuss the milestones and depending on the discussion I can
> modify the proposal before its final submission.
>
>
>
>> You haven't mentioned other applications.  Google rules allow up to 5,
>> to different projects with one organization or to multiple
>> organzations.  I recommend against submitting more than 3 as a waste
>> of your energy and probably will detract from your evaluation on all
>> of them.  But nobody's feelings will be hurt if you do submit to other
>> organizations.  I would appreciate knowing as early as possible if you
>> have other prospects (in or out of GSoC).  This will not affect your
>> evaluation in Mailman.
>>
>
> I will be submitting only one proposal, that is in Mailman. Actually, I
> haven't yet been able to find any other projects suitably interesting for
> submitting a proposal.
> So Mailman will remain as the top priority submission for me!
> Also, I will be having my college summer vacations from mid May to July
> end, and have no prior commitments for this period, and in August since
> college will have just reopened I will have enough time to work on the
> project.
>
> I did not know if the proposal is to be CC'ed to the mailing list at this
> stage, and since the previous mail did not CC the mailing list, I have
> followed suit. Hope its not a problem :)
>
> Thanks!
>
> Aditya.
>
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Regarding my previous mail,
I have implicitly assumed that the testing would involve the use of
examples which do not have a pre-existing valid ARC chain in them i.e. the
test examples would not be containing mails which have multiple ARC set of
headers, and that the ARC chain would be first initiated by Mailman. Such
examples cannot be used for testing before all the milestones are completed
due to the arc verification test being implemented at the end.
We can, however implement such examples in the testing process once the
entire code is completed, since then the arc verification will be in place.
Also, this can be added as a milestone after all the previously mentioned
milestones are complete or can be merged with milestone 8.

Thanks.

Aditya.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve,
As discussed in our earlier conversation, I went over the milestones again
and made some changes.
We would need to use the approach of creating our own examples in the
milestone for the AS code (milestone 6, for testing) too, since the AS
signs over the previous generated set of headers. This will however not be
a problem since the AMS and AAR code should be already completed by that
point thus enabling the creation of test example.
And as said before, the second time this approach would be used in
milestone 7. The reordering of the arc verification after the completion of
the AMS and the AS should not be a problem since the AMS and AS code do not
refer explicitly to the arc verification field in the AAR. Both of them use
the AAR in their signing[1] as a whole field and are not concerned with its
individual fields, and hence the addition of arc at a later stage should
not create any problem. Also the examples used for testing by us in
milestone 5 and 6 would not involve the `arc = ` field since the example
mail will be consisting of the first instance of the ARC headers i.e. `i =
1`, and hence the arc verification test would not be performed (i.e. no
`arc = ` field in the AAR), even after the code for it is inserted in its
place, thus keeping the tests in milestones 5 and 6 valid.

Milestones -

1. ARC Authentication Result - spf verification code completed. tests
passed. merge request created.

2. ARC Authentication Result - dkim verification code completed. tests
passed. merge request created.

3. ARC Authentication Result - dmarc verification code completed. tests
passed. merge request created.

4. ARC Authentication Result - generate AAR header from the previous
milestones code. tests passed. merge request created.

5. ARC Message Signature code completed. tests passed. merge request
created.

6. ARC Seal code completed. tests passed. merge request created.

7. ARC Authentication Result - arc verification code completed. tests
passed. (The workflow is modified to make the mail pass through this
function after milestone 3 [2] ). merge request created.

8. The mail is prepended with the complete set of ARC headers. Tests for
checking the entire ARC set of headers passed. merge request created
(tests).

Comments on testing -

1. For spf testing  - The spf library itself provides test examples, and
mails can be extracted (i.e. the part before gmail adds its own
authentication results) from gmail using the `Show Original` feature. These
mails can be used for testing purposes.

2. For dkim testing - The dkim library provides testing examples, and
similar to above, mails may be used from gmail.

3. For dmarc testing - The examples for this can be gathered from our gmail
account. Any mail sent from yahoo's domain to a gmail account
will have dmarc verification performed. A mail extracted so can be used for
testing purposes by us.

4. Testing this would require testing of the format of the generated AAR
against the official RFC7601 format for authentication results (since the
values of the individual fields have already been tested above) i.e.
keeping track of the delimiters, white spaces, and the correct prepending.
The AAR header generated for an example mail from the above code can be
used here, and tested against the format outlined in the ARC draft.

5. ARC Message Signature testing - We can generate the signature for a
given example mail from the written code, and generate a signature using
the same set of headers from the dkim package (keeping track of the
implicit and explicit headers). The crucial part would be matching the
signatures, i.e. the "b" tag, and matching the body hash, i.e. the "bh"
tag. The "t" tag would differ since it depends on the exact time, and the
"i","a","s","d", "h" tags can be checked manually.

6. ARC Seal testing - For this we could use the previously defined AAR and
AMS, and the current AS code to generate a mail with the full ARC set of
headers (the AS would sign over the AAR and the AMS generated in the
previous milestones). An example mail could be then passed through the
above code, and then can be used for testing purposes (Here we would need
the approach of generating our example from the code as you mentioned).
Here too, the "i", "a" , "s" , "d" , "cv " tags can be checked manually and
the "t" tag would differ. Hence the crucial tag would be the "b" tag.

7. The code for the arc verification test is completed. We can now perform
the arc verification test here. A fully cooked mail with the ARC headers
can be prepared from the above code for the `pass` test . For a `fail`
test, we can make some manual changes in the AS to invalidate it, and then
perform arc verification on it.

8. Here the testing for the complete ARC set of headers would need to be
performed. An example mail can be passed through the above entire code, and
manually asserted in the test. (Since the individual fields would have
already been tested, the main aim here would be testing that the ARC

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Stephen J. Turnbull]

Aditya Divekar writes:

 > Yes, in that case the arc verification would need to be postponed to after
 > the entire code for the header generation has been written. I'll need to
 > rethink the milestones a bit, since this testing part would have to be
 > added at the end, and things will change quite a bit.

That's what I wanted to hear!  We're making rapid progress!

Let me know your thoughts on milestones.  There's no huge hurry, since
applications haven't even opened yet.

 > On a side note, would posting on the arc-discuss list for help in
 > the above problem of testing be acceptable?

Yes, but not yet.  I should probably review your first post or two
before posting, as well.  There are plenty of friendly, helpful people
on the IETF lists[1], but the lists themselves are rather different in
tone and style from most open-source projects.

Footnotes: 
[1]  Technically arc-discuss is hosted by dmarc.org, not the IETF, but
it's the same people.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve,


> The problem is how do you get such a message?  The easiest way is if
> you have implemented the creation functions for the ARC-* fields.
>
> Then you can check that you can roundtrip your own fields (create and
> verify).  Of course you will eventually need to test against other
> implementations (currently Google and AOL have implementations that I
> know of), but for now it makes sense to "eat your own dogfood"
>

Yes, in that case the arc verification would need to be postponed to after
the entire code for the header generation has been written. I'll need to
rethink the milestones a bit, since this testing part would have to be
added at the end, and things will change quite a bit.
I'll work this out properly and reach back to you.

On a side note, would posting on the arc-discuss list for help in the above
problem of testing be acceptable?

Thanks

Aditya
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Stephen J. Turnbull]

Aditya Divekar writes:

 > >  > 4. ARC Authentication Result - arc verification code completed. tests
 > >  > passed. merge request created.
 > >
 > > How do you propose to create tests for #4?
 > >
 > >
 > Here, we could consider a few scenarios-
 > 1. A message is passed to the function which does not have any previous ARC
 > headers. In this case the verification is not performed.
 > 2. A message containing a valid ARC chain is passed to the
 >function.

The problem is how do you get such a message?  The easiest way is if
you have implemented the creation functions for the ARC-* fields.

Then you can check that you can roundtrip your own fields (create and
verify).  Of course you will eventually need to test against other
implementations (currently Google and AOL have implementations that I
know of), but for now it makes sense to "eat your own dogfood".

Regards,
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

> Stephen Turnbull writes:
> This is all already in the message or msg_data objects, except for the
> value of "i" itself.  So I'm not sure what you're saying.  My point is
> merely that any header field mentioned in any of the relevant RFCs
> that can be validated must be validated to conform to ARC.
>
> By extraction I meant that the message could be parsed to get back a tuple
of "headers, body" where the headers would be returned as lists containing
the name and value. And then all the required headers could be used for the
authentication purposes.
But since we will be receiving a processed mail from Mailman (msg_data), as
mentioned, the parsing won't be required.


> I'm not sure you will need so many separate modules; each verification
> depending on existing standard can probably be kept to a single
> function, unless you can't get all relevant information from the
> upstream modules.  But it doesn't hurt to separate them now, and think
> about combining them later, if that's convenient for you.
>
>
Yes, I meant to refer to separate functions here actually.
By modules I meant that the code for each would be independent, and can be
implemented as processes that the mail through.
Creating separate functions would help in debugging processes. Sorry for
the slip.


>  > 4. ARC Authentication Result - arc verification code completed. tests
>  > passed. merge request created.
>
> How do you propose to create tests for #4?
>
>
Here, we could consider a few scenarios-
1. A message is passed to the function which does not have any previous ARC
headers. In this case the verification is not performed.
2. A message containing a valid ARC chain is passed to the function. In
this case the verification is performed and the most recent ARC Seal is
tested for authenticity, which can be checked in the test.

This would get difficult if we are dealing with cases where the previous
ARC chain is longer than 1 or 2, since it would involve extracting all the
ARC headers in the message ( tricky, since all the headers have the same
"tag", i.e. - all the headers would be named the same - "ARC Message
Signature:", "ARC Seal:", and can be differentiated only on the basis of
the "i" value ), since the most recent ARC Seal will sign over all these,
and hence we need them for the verification process.

Here, a case could occur (if possible) where the message contains a broken
ARC chain, i.e. the last MTA did not add its ARC set of headers. This would
happen if it is assumed that not all MTAs are enforcing ARC.
It is not clear from the draft to me if in this case the arc verification
would have to be performed, since the draft assumes that all the
intermediaries participate in the ARC system. According to me since the
chain is broken, it would not be required to verify the ARC headers.
I would like to know how you think this case can be handled.

Thanks

Aditya
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Stephen J. Turnbull]

Aditya Divekar writes:

 > Depending on the message, if it has previous Authentication Results added
 > as a header, that can be extracted too.  The entire message can be parsed,
 > and then all the possible headers involved in the authentication process,
 > ie. DKIM signature, Authentication results, ARC headers,  can be
 >  extracted. If not found, a suitable flag can be set for them. ie. example
 > - if no previous arc headers were found, a flag can be set. This can later
 > be used in deciding the flow of the mail such as the "i" tag value, whether
 > we need to perform ARC authentication for the previous ARC headers, and
 > other fields that depend on the occurrences of any previous ARC
 > set.

This is all already in the message or msg_data objects, except for the
value of "i" itself.  So I'm not sure what you're saying.  My point is
merely that any header field mentioned in any of the relevant RFCs
that can be validated must be validated to conform to ARC.

 > Okay.! So we need to only include the ARC Headers and forward the
 > message to the subscribers, and leave it upto their MTAs to do the
 > needful.

Yes.

 > I have come up with the following probable milestones for the
 > project. -

Looks good.  I have a couple of comments.

 > (The project has been divided into milestones on the basis of the separate
 > modules that will be created. Each module is a milestone).

I'm not sure you will need so many separate modules; each verification
depending on existing standard can probably be kept to a single
function, unless you can't get all relevant information from the
upstream modules.  But it doesn't hurt to separate them now, and think
about combining them later, if that's convenient for you.

 > 1. ARC Authentication Result - spf verification code completed. tests
 > passed. merge request created.
 > 2. ARC Authentication Result - dkim verification code completed. tests
 > passed. merge request created.
 > 3. ARC Authentication Result - dmarc verification code completed. tests
 > passed. merge request created.
 > 4. ARC Authentication Result - arc verification code completed. tests
 > passed. merge request created.

How do you propose to create tests for #4?

 > 5. ARC Authentication Result - generate AAR from the previous milestones
 > code. tests passed. merge request created.
 > 6. ARC Message Signature code completed. tests passed. merge request
 > created.
 > 7. ARC Seal code completed. tests passed. merge request created.
 > 8. Generate the ARC set of headers from the previous milestones code, and
 > prepend them to the message.
 > tests passed. merge request created.
 > 
 > *As you mentioned, branch coverage will be the aim behind all the tests for
 > each module (Branch coverage would mean considering all possible scenarios
 > of the workflow).
 > 
 > Notes -
 > 
 > 1. I've broken down the AAR set into different milestones, since each
 > method will require the use of different functions and packages. (ie. spf,
 > dkim, dmarc, arc).
 > 
 > 2. Regarding milestone 8, separate modules will be responsible for
 > generating the components of the ARC header set, and these can be combined
 > at the end for getting the complete ARC set. This will be useful for
 > testing purposes.
 > 
 > 3. We need to perform the dmarc testing manually since the gs.dmarc package
 > only provides the dmarc policy query functionality. The gs.dmarc package
 > can be used to query the dmarc record of the RFC5322.From domain. Then we
 > can verify using the aspf and adkim relaxed/strict tag values and the
 > spf/dkim results whether the dmarc authentication is a pass or fail, as
 > given in the RFC7489 draft (dmarc draft). Is there a better alternative to
 > this in your knowledge?

No.

 > I would like your opinion on these milestones, and if possible your
 > ideas can be merged with these to come up with a better list :)

No, your list is workable and basically similar to mine, except for
the ordering comment on #4.  I think we should develop your ideas
first, then compare.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve!


> This should be trivial to do with the Python email package, too.  I
> don't really see that a separate module would be useful, since we'll
> want to extract a fixed set of headers (ARC- and DKIM-specified).  Of
> course it should be factored into a separate function (or perhaps a
> generic "extract_fields" function and a couple of derivatives with the
> DKIM list (just DKIM-Signature?) and the ARC list (ARC-Seal,
> ARC-Authentication-Results, and ARC-Message-Signature).
>
>
Depending on the message, if it has previous Authentication Results added
as a header, that can be extracted too.  The entire message can be parsed,
and then all the possible headers involved in the authentication process,
ie. DKIM signature, Authentication results, ARC headers,  can be
 extracted. If not found, a suitable flag can be set for them. ie. example
- if no previous arc headers were found, a flag can be set. This can later
be used in deciding the flow of the mail such as the "i" tag value, whether
we need to perform ARC authentication for the previous ARC headers, and
other fields that depend on the occurrences of any previous ARC set.

Another factoring issue: should you "import dkimpy" and call

> dkimpy.foo, or should you "from dkimpy import foo, bar, baz"?
> (Doesn't need to be settled for a while, and you can even try both at
> a small cost in time and effort.)
>
> From what I've read, I should use the `from ... import ...` when the no of
methods required from the package is less, around 3-4, the entire package
is not required and when naming conflicts are to be minded.
But yes, I can settle it later during the coding part :)

 >Isn't this inaccurate?  This "i" must *match* the Seal "i", no?

Yes, I meant the same thing. The "i" tag for all the three AAR, AMS and the
AS will be the same , and will be one higher than the previous instance of
the "i" tag. If no previous instance is there, it will be 1.

 > a,t,s,d: These can again be obtained from the dkimpy package.
>  >
>  > bh: The body hash. This can be obtained from the package. Here, we set
> the
>  > canonicalization to 'relaxed' and get the body hash.
>
> "The package" == dkimpy, right?
>
> Yes.


>  > 3. ARC Authentication Results.
>  > The "i" tag simply takes on the value same as the above "i" tags.
>  > Now from our previous conversation, as you suggested, the
>  > authenticity of the previous MTA who sent us the mail is not sure
>  > to be trusted. So in the case where we don't trust the previous
>  > MTA, we will have to perform our own DMARC, SPF, DKIM testing of
>  > the recieved mail. If previous ARC chain exists i.e. cv=V, then we
>  > perform the ARC test too.
>
> I'm not sure you understood me.  We *always* verify the preceding
> MTA's claims, even if we trust them, because of spoofing and
> man-in-the-middle attacks on the Internet itself.  (More precisely,
> verification is required by the I-D, and the rationale is spoofing and
> MITM.)  The MTA we "may or may not trust" is our *own* MTA.
>
>
Yes. So for every mail we receive, we always perform the authentication
tests for spf,dkim, dmarc (and arc if present).


> No.  The mail cannot be proved authentic by ARC, but that may be due
> to changes to the message at intervening hops.  There may be more
> sophisticated tests (eg, a PGP signature on a MIME body) that can
> prove it authentic.
>
>
Okay.! So we need to only include the ARC Headers and forward the message
to the subscribers, and
leave it upto their MTAs to do the needful.

 > Now coming to the testing part. There can be a number of tests like
>  > verifying the generated ARC signature, changing the body of the
>  > message, failing when the implicitly signed AMS headers are changed
>  > and other such tests.
>
> This is a little vague, but testing is hard.  You'll learn it as you
> go along.
>

I will come up with at least a few concrete tests that need to be performed
for each of the modules given below (in the milestones), and run them by
you once before the proposal.

>
> I count about 9 well-defined tasks in your message that could be made
> into good milestones.  You should try to come up with your own list,
> but if you're really not happy with your list, send it to me and ask
> for help and I'll give you my ideas.
>
>
I have come up with the following probable milestones for the project. -
(The project has been divided into milestones on the basis of the separate
modules that will be created. Each module is a milestone).
1. ARC Authentication Result - spf verification code completed. tests
passed. merge request created.
2. ARC Authentication Result - dkim verification code completed. tests
passed. merge request created.
3. ARC Authentication Result - dmarc verification code completed. tests
passed. merge request created.
4. ARC Authentication Result - arc verification code completed. tests
passed. merge request created.
5. ARC Authentication Result - generate AAR from the previous milestones
code. tests passed. merge