Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

On Fri, Dec 1, 2017 at 10:09 AM, Kurt Andersen (b) wrote: > > Where would you like to gather such a consensus? Is this DMARC-WG > sufficient or would you want input from a wider community? > Here's fine. Or the ART list, or ietf-822. Or really, anywhere the IETF considers "on-the-record" in te

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank wrote: > Replace 5.1.1 with: > > 5.1.1. ptypes and properties for arc-info > > Certain information pertinent to ascertaining message disposition can be > lost in transit when messages are handled by intermediaries. For example, > failing DKIM signatures

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

Omitting stylistic nits for now: On Wed, Nov 22, 2017 at 9:34 PM, Seth Blank wrote: > 16 Experimental Considerations > > [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be > removed by the document editor, or should it stay with the document as long > as it’s experimental?

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

On Wed, Nov 29, 2017 at 9:17 AM, Kurt Andersen (b) wrote: > While I have a number of issues with the details of the proposal, I'll > tackle those in another thread. The fundamental problem that I have with > the whole "experiment" approach is that it is something like throwing a > baseball into a

Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba wrote: > We also need to understand whether there's really anything we intend > to do with DMARC. Do we *know* what we might do? Do we have any plan > for a way forward? Are we hoping that ARC will fix enough of it that > we can make the combination

[dmarc-ietf] ARC and "fail" again

At the risk of bringing up the whole "cv=invalid" debate again... When a chain is invalid (say, an AMS is missing), Section 9.3 says to add a seal that only covers itself but uses N+1 for its "i=" value. Could someone propose some informational text for the draft that explains why that decision w

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.txt

On Thu, Sep 7, 2017 at 10:11 AM, Seth Blank wrote: > I'll go over this in more detail and post substantive comments sometime in > the next day or so, but at first glance, a crucial change in 5.1 was missed > and the draft language still makes a normative change to 7601 ("data SHOULD > be added to

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana wrote: > On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote: > > On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote: > > We went down the path of including a diff of the message in the headers, > but you run up agains

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote: > We went down the path of including a diff of the message in the headers, > but you run up against more complicated changes that make that > challenging. Ie, mailing lists which strip attachments. If all we cared > about were subject munging

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker wrote: > On 8/18/2017 10:00 AM, Seth Blank wrote: > >> >> Right now, we've got deployed code that we know works and improves the >> landscape. Everything else is - rightly or wrongly - conjecture. >> > > > Personal Point of order: > >Using an 'in

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank wrote: > On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana > wrote: >> >> I laugh as well, but it's more than p=reject isn't enough in the ARC >> world, because it doesn't distinguish between: >> a) I'm OK with email from my domain being sent via mailing

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: > > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can&#

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > Goodness, it's a wonder that we've

Re: [dmarc-ietf] Review of draft-ietf-dmarc-arc-protocol-07

On Tue, Jul 25, 2017 at 10:00 AM, Alexey Melnikov wrote: > I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so > some of the issues identified below might no longer be relevant: > > 1) The new abstract doesn't even use the word "email". This needs to be > fixed, because otherwise

Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n]

On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: > There has been an on-list discussion about this, but in it no consensus > was reached: https://mailarchive.ietf.org/arch/msg/dmarc/ > KvpNpf_9ywZpK6oMcwJ1OJthiHM > > Off list the consensus from those I've spoken with (which is obviously not > n

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen wrote: > > I don't understand. Mediators ARC sign, the header is everything you need >> for this identification, is it not? >> > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the mailing lists. If IETF

Re: [dmarc-ietf] Agenda for IETF99 F2F

Status reports are great list material. I don't think it's useful for mic time. Unless something specific about OpenARC is germane to the draft(s), I feel we have plenty of other stuff to discuss during face time. On Sun, Jul 16, 2017 at 9:51 AM, Barry Leiba wrote: > > Why is OpenARC's status

Re: [dmarc-ietf] [arc-discuss] openarc defer messages

On Sat, Jul 15, 2017 at 2:43 AM, Kurt Andersen wrote: > On Sat, Jul 15, 2017 at 11:28 AM, Juri Haberland > wrote: > >> On 15.07.2017 10:33, Kurt Andersen wrote: >> >> > But if the parsing fails, then it was hanging and causing message >> deferral, >> > even if the AuthServID would have disqualif

Re: [dmarc-ietf] Agenda for IETF99 F2F

Why is OpenARC's status an IETF agenda item? On Sat, Jul 15, 2017 at 12:46 AM, Kurt Andersen wrote: > If there are any missing items, please let us know as early as you can. > Here's the proposed agenda: https://datatracker. > ietf.org/meeting/99/agenda/dmarc/ > > --Kurt > >

Re: [dmarc-ietf] using selectors to identify sources

On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) wrote: > > 1) Include the additional information in the AAR which is wanted > downstream for a DMARC report to be emitted from a receiver N hops away - > this requires additional fields to the basic RFC7601 A-R spec > This seems to be the least

Re: [dmarc-ietf] ARC RFC status to target

On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) wrote: > Regarding timelines, I think that we can have wishes and hopes, but, since > we will now be holding our seventh(!) interop event during the IETF99 > hackathon, I don't expect that "months" is even the right scale upon which > to base our

Re: [dmarc-ietf] using selectors to identify sources

On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > I think it needs to be specified. Receivers construct DMARC reports in a > known manner, they shouldn't need to guess how to get the appropriate > information out of ARC headers in an intermediary-implementation-specific > manner. The spec shoul

Re: [dmarc-ietf] using selectors to identify sources

On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy > wrote: > >> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: >> >>> Or maybe, put a different way, the question is: what's the simplest way, >>

Re: [dmarc-ietf] ARC RFC status to target

On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker wrote: > 2. The mechanics of cascading signatures that ARC does /is/ unusual > and possibly unique. I believe the only operationally established exemplar > in this space is the X.509 cert signature hierarchy. However it is an > relatively static,

Re: [dmarc-ietf] using selectors to identify sources

On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: > Or maybe, put a different way, the question is: what's the simplest way, > with the least delta to the spec, that allows for transmission of selectors > and source ip? This would enable DMARC reports for messages delivered due > to ARC to have

Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker wrote: > I've come to believe that it makes more sense, at this stage, to seek a > status of Experimental. That's not meant as a criticism of the work, but > rather to accurately reflect the current understanding of ARC dynamics. > > Having intermedi

Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 7, 2017 at 12:50 PM, Steven M Jones wrote: > I may be misreading your response, but I wasn't suggesting a timeline > without criteria. I would hope to see criteria and a provisional > timeline for when to apply them. "A, B, and C will be tracked and > evaluated at IETF 101, next move

Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan wrote: > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. I think that is aligned with (but not entailed by) > https://www.ietf.org/iesg/informat

Re: [dmarc-ietf] using selectors to identify sources

On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman wrote: > In this context, having the selector in DMARC feedback reporting to help > define a 'source' is really useful. > The DMARC report also includes other things that might be able to help you identify the bad source, like the IP address. But

Re: [dmarc-ietf] selectors in AAR.

On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank wrote: > This thread is only about encapsulating information useful for a consumer > of DMARC reports, as that consumer will not have the message and its > headers. Selectors are critical here for tying things together. > > The DMARC report data is gene

Re: [dmarc-ietf] selectors in AAR.

On Wed, Jul 5, 2017 at 4:36 PM, Seth Blank wrote: > The *only* intent here is to report back services that break > authentication to the domain owner in a DMARC report. As such, the selector > disambiguates services (especially when there are multiple hops, some of > which might have the same d=)

Re: [dmarc-ietf] selectors in AAR.

On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy > wrote: > >> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein >> wrote: >> >>> So as a consumer of these reports I'd definitely like t

Re: [dmarc-ietf] new arc usage

On Fri, Jun 30, 2017 at 2:45 PM, Brandon Long wrote: > Someone's using a keysize of 4098... that's odd. > That Dave Crocker did not take this opportunity to say "No it's not, it's even" must mean he's traveling. -MSK ___ dmarc mailing list dmarc@ietf.

Re: [dmarc-ietf] ARC cv=invalid

On Wed, Jun 21, 2017 at 6:19 PM, Seth Blank wrote: > On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote: >> >> If you put arc=fail in an AR and then the next hop ignores and strips the >>> AR (per spec), what good is it? >>> >> >> None, but what good is the broken chain? If all you're doing is

Re: [dmarc-ietf] ARC cv=invalid

On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote: > On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) > wrote: > >> On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman >> wrote: >> >>> >>> It seems we have two choices available to us upon receipt of an invalid >>> chain(which is defined as AS b= u

Re: [dmarc-ietf] Valimail and DMARC

On Sat, Jun 3, 2017 at 3:32 AM, Ken O'Driscoll wrote: > Not to mention, the irony of the official DMARC mailing list discouraging > postings from DMARC protected domains due to compatibility issues! > Not long ago there was some advice circulated that DMARC is really only for protecting domains

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman wrote: > I don't have particularly strong opinions here. I can see no reason for > the d= to differ, but also no harm in allowing it do so. So I think the > question of what to do here is slightly more philosophical. I think I > generally fall on the

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) >> wrote: >> >>> There's another question that had been raised by Seth abou

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy > wrote: > >> Another way to look at it: A-R is meant to be a channel to record what >> authentication was done and what thing in the visible message got >

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Wed, May 31, 2017 at 10:30 PM, Seth Blank wrote: > > So I guess returning to the original thread, there are two matters: > > 1) Should we stamp header.b in the A-R? (consensus seems to be yes) > It's defined, may as well use it. > 2) How should we transmit the source_ip for the DMARC report

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein wrote: > So as a consumer of these reports I'd definitely like to see a structured > value with as much information as possible. > > The ideal would be to get as much information as we'd get if the final > receiver had seen the original email direct

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

On Wed, May 31, 2017 at 5:47 AM, Barry Leiba wrote: > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. > > Does anyone think we *should* proceed with writing this?

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > 2) smtp.client-id > > > > The goal here is to track the originating source_ip for DMARC > > categorization and reporting. Otherwise, all ARC messages will have a > DMARC > > repor

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) wrote: > There's another question that had been raised by Seth about whether d= > needs to match within an ARC set. The answer is yes, [...] > Why? -MSK ___ dmarc mailing list dmarc@ietf.org https://w

Re: [dmarc-ietf] cv=invalid

On Wed, May 31, 2017 at 6:40 PM, Kurt Andersen (b) wrote: > If a verifier decides an ARC is invalid, it's supposed to set >> "cv=invalid", when generating its own ARC-Seal. This seems odd; we're >> cryptographically signing a chain that is known to be broken, meaning the >> next handler might no

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Tue, May 30, 2017 at 10:33 AM, Scott Kitterman wrote: > > At some point in the process, an AAR and ARC signature get created. Later, > someone else has to validate them. > > My point was that when you are on the signing end of this, you have to > grovel > through all the relevant AR header fie

Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature

SHOULD be the same? I can't think of a good thing to say here, or a solid justification for any choice. I can't imagine why they would ever differ, but I can't come up with a solid technical reason to demand it either. As a verifier I might be skeptical if they're wildly different names, but tha

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Wed, May 31, 2017 at 3:25 PM, A. Schulze wrote: > > I can give an update on the list. > please :-) OpenARC is effectively in an Alpha state, implementing the -03 draft. The code is available via github. It is correctly validating and generating seals and signatures and generating ARC-Authe

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > I've taken a look at the proposed draft and have a few notes as well. > > 4. The currently specified limits on i= are not included MUST >10, SHOULD > > 50, etc > 50 seems oddly high. I think sendmail out-of-the-box limits you to 20 Received

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > In 5.1 defining the AMS, you say that it should cover DKIM-Signature and > AuthRes headers. In particular, AuthRes headers are expected to be removed > by ADMDs, especially if the message transits the same ADMD multiple times. > Also, the inf

Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC)

On Tue, May 30, 2017 at 10:50 PM, Kurt Andersen (b) wrote: > (Reposting with adjusted subject) > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) > wrote: > >> Barry et al, >> >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: >> >>> The current spec defines an arc authres method ( >>> h

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Wed, May 24, 2017 at 3:55 PM, Seth Blank wrote: > Looping back about this. > > Currently openarc only supports relaxed canonicalization for the ARC > Message Signature. > > On closer inspection, https://tools.ietf.org/html/dr > aft-ietf-dmarc-arc-protocol-03#section-5.1.2 and > https://tools.i

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 3:08 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > > wrote: >> >>> What benefit is there to covering AAR with both the AMS and th

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Tue, May 30, 2017 at 7:57 AM, A. Schulze wrote: > Am 29.05.2017 um 18:49 schrieb Barry Leiba: > > We've had one request for a DMARC session in Prague, with no further > > response from the working group. > > I didn't follow all ARC discussion over the last months. An update > is welcome. Also

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Mon, May 29, 2017 at 9:49 AM, Barry Leiba wrote: > We've had one request for a DMARC session in Prague, with no further > response from the working group. > > We've had one suggestion for an interop test in Prague, with no > further response from the working group. > > I would like to schedule

[dmarc-ietf] cv=invalid

I think this was discussed before, but perhaps it didn't reach a logical conclusion: If a verifier decides an ARC is invalid, it's supposed to set "cv=invalid", when generating its own ARC-Seal. This seems odd; we're cryptographically signing a chain that is known to be broken, meaning the next h

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy wrote: > > What's the added value in covering AAR[n] twice, once with its b= and once > without? > > Sorry, that got out before my thought was fully formed. What benefit is there to covering AAR with both the AMS and the

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Tue, May 30, 2017 at 6:38 PM, Kurt Andersen (b) wrote: > On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote: > >> This might be a non-issue, but we're asking this question specifically >> because we've run into an implementation issue within openarc that feels >> weird and seems like a matter

[dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

Colleagues, As I progress (slowly, alas) toward completing my sample implementation of OpenARC, I've found myself taking a lot of notes about the current draft. This has helped me make progress; in some cases it became things I posted to the list, and in others it was just to help or confirm my un

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

On Fri, Apr 7, 2017 at 8:33 AM, Peter Goldstein wrote: > Does this initiative include an intention to update the cryptographic > guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter > speaks of adding new algorithms, but doesn't discuss deprecating/removing > old ones. > As John

Re: [dmarc-ietf] ARC-Authentication-Results

On Mon, Apr 3, 2017 at 8:06 PM, Scott Kitterman wrote: > That makes more sense, but raises another concern then. It seems > misnamed. A-A-R isn't an ARC result at all, it's part of the input to the > ARC process. > I think it's not named that way because it's conveying an ARC result, but rathe

Re: [dmarc-ietf] ARC-Authentication-Results

On Tue, Apr 4, 2017 at 5:28 AM, Kurt Andersen wrote: > The grammar is indeed terrible and needs to be fixed. The intent is that > the AAR reflects the computed A-R at the time the message enters a trust > boundary. Only the A-R that it computes is put into its ARC set as the AAR. > Depending upon

Re: [dmarc-ietf] ARC-Authentication-Results

On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long wrote: > Knowing what the previous ADMD thought is explicitly a goal of ARC. The > theory is, the first hop said that it was from yahoo.com and DKIM > signature matched, and then the mailing list changed it so the DKIM > signature is now broken, but I

Re: [dmarc-ietf] ARC-Authentication-Results

On Mon, Apr 3, 2017 at 5:47 PM, Scott Kitterman wrote: > I'm also not clear why we need a new header field. Why can ARC be a new > method for A-R? > The idea, as I understood it, is for AAR to record what a particular ADMD saw at ingress from DKIM and SPF (and maybe others), not to record what

Re: [dmarc-ietf] ARC-Authentication-Results

On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones wrote: > My POV, there is a strong 1:1 correlation between a set of ARC headers and > a given ADMD. In this world view, the A-A-R would *not* collect all A-R > values from all preceding ADMDs. > It depends on what the goal is. If you only want to r

Re: [dmarc-ietf] ARC-Authentication-Results

On Mon, Apr 3, 2017 at 5:21 PM, Brandon Long wrote: > My goal for this is that you would only collect the auth-res header for > the same admd and the same delivery step as is doing the arc-signing. > > Ie, if you assumed that there was a single Auth-Res header added during > the smtp phase, you w

Re: [dmarc-ietf] ARC-Authentication-Results

On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy wrote: > > As a final recipient, I'd have no idea what to do with that. > I'd be happy to propose alternative text to what's there, but first I'd like to understand what the downstream receivers

[dmarc-ietf] ARC-Authentication-Results

The latest ARC base document says this about the ARC-Authentication-Results field: ARC-Authentication-Results is a direct copy of the Authentication- Results header field [RFC7601 ] created for archival purposes by the each MTA outside of the trust bou

Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification

Please be sure to read RFC7601 while deciding, as it sets out the rules for the registries related to Authentication-Results and what's appropriate to put in them. On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada wrote: > Mark > > Thank you for your comment. > > The authors are now discussing which

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

Hi Seth, Can you describe in detail the fragility you've observed? I saw Peter (sorry for "Paul", it was 4am) upthread somewhere say that a few different projects had various problems found, but I don't recall him saying exactly what they were. -MSK On Fri, Mar 31, 2017 at 11:13 AM, Seth Blank

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman wrote: > What's more difficult to is identify all the ways that things get > reordered, > mangled, etc as they transit the various elements of the mail architecture. > If you over specify the allowed order, aren't you risking increasing the > brit

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

On Mon, Mar 27, 2017 at 1:06 PM, Brandon Long wrote: > What does validating the exact signature generated benefit us over just > verifying that the signature verifies? > The most obvious benefit I can think of is that the output of signing is entirely deterministic. You could test it with strcm

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

On Sun, Mar 26, 2017 at 11:25 PM, Peter Goldstein wrote: > Second, the premise that "it's not hard to write test code..." is simply > not true. What would be required to actually write such code would be > either a) pick a preferred ordering/formatting for these tags, and only > have the tests p

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

I have to catch up on the rest of this thread still, but I wanted to chime in here to get started: On Sun, Mar 26, 2017 at 5:23 PM, Gene Shuman wrote: > Ah that had slipped my mind & is a good point. However, I think the issue > here is generally that ARC is more complex protocol than DKIM and

Re: [dmarc-ietf] "Missed it by *that* much". . .

On Thu, Mar 16, 2017 at 5:23 PM, John Levine wrote: > In article gmail.com> you write: > >I'm not sure how you could go about registering key lengths. What do you > >have in mind? > > Come to DISPATCH and learn all about it. > Oh, don't you worry. :-) The general point is that DKIM's key adv

Re: [dmarc-ietf] "Missed it by *that* much". . .

On Wed, Mar 15, 2017 at 4:18 PM, Kurt Andersen wrote: > I discovered today as I attempted to submit the ARC protocol update that > I've been working on, that the submission system closed about 40 hours > earlier - sigh. > > Since I'm headed to Ecuador for a three week vacation with unknown and/or

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

On Mon, Jan 23, 2017 at 10:58 AM, John Levine wrote: > >It's been awhile since I've seen this, so it may not be a problem > anymore. There is no obviously correct > >thing that someone won't screw up. > > > >It's probably better to specify how to put multiple strings together. > RFC 7208 has wor

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Mon, Jan 23, 2017 at 9:50 AM, Matt Simerson wrote: > > LOL. EC is currently quite robust but let’s not forget that we are but one > novel new attack away from those faster crypto operations becoming a > liability. Then we’ll all be jacking up our EC key lengths to compensate. > The last time

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Sun, Jan 22, 2017 at 3:49 PM, Scott Kitterman wrote: > > In theory, sure. In practice it's just a variation on waiting for someone > else to do the work. Additionally, DKIM will have an added burden of > gaining community consensus that the security benefits of the change are > important eno

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Sun, Jan 22, 2017 at 1:46 PM, Kurt Andersen wrote: > > Don't you think it would be better to "fix" the DKIM spec than to have ARC > "do its own thing"? > > I would argue that we're not chartered to update DKIM for this purpose, though I'm happy to do that as an individual submission if we can

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman wrote: > No responsible operator has used the RFC minimum DKIM key sizes for a long > time. They were trivial to bypass half a decade ago. No one has ever > complained about 1024 bits default minimum being too big. I did once get a > complaint ab

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Sun, Jan 22, 2017 at 2:25 PM, Peter Goldstein wrote: > Kurt, > > I agree that the best approach would be to update the DKIM spec to reflect > modern cryptographic realities. > I'd like to come up with something better than updating DKIM every time there's new advice on key sizes, etc. Doing

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: > > The intent of section 5.2.1 was never to deal with pathological cases. It > was to deal with somewhat broken MTAs that do stupid things like reordering > headers in alphabetical order or slightly broken implementations which > might repli

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman wrote: > I think its clear that we fail all of these messages. But for signing, we > need to specify an ordering on these pathological arc headers, as section > [5.2.1] only applies when you can logically define arc sets. We also > probably need this

Re: [dmarc-ietf] ARC draft issues/clarifications

On Thu, Jan 12, 2017 at 1:34 PM, John Levine wrote: > In article gmail.com> you write: > >I'm currently working on a test suite for ARC, and have run into a few > >areas in the draft that could use some clarification, mostly with regards > >to section 5.2.1, which seems like it needs a non-trivi

Re: [dmarc-ietf] Prodding for reviews... and planning NOT to have a meeting in Chicago

On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen wrote: > 1) Murray had promised some ideas for restructuring the draft to make it > more understandable, but I haven't received them yet. > > I've been making notes about this as I complete the first releasable version of OpenARC. I think it's there

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

On Thu, Nov 24, 2016 at 1:14 PM, Marco Davids (IETF IMAP) < marco.dav...@sidn.nl> wrote: > On 24/11/2016 21:40, Murray S. Kucherawy wrote: > > +1 to Terry's points. On the other hand, "fi" is described mainly as > > a request (modulo the SHOULD NOT, which i

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

On Thu, Nov 24, 2016 at 1:51 AM, Marco Davids (IETF IMAP) < marco.dav...@sidn.nl> wrote: > Dear community, > > I hereby request feedback and support for draft-davids-dmarc-fi-tag. > [...] > I seem to recall debating this idea during the pre-IETF work on DMARC. I also seem to recall it being remo

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

+1 to Terry's points. On the other hand, "fi" is described mainly as a request (modulo the SHOULD NOT, which is debatable in my opinion) which means DMARC verifiers are free to ignore it. On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink wrote: > Why would a large email receiver build out its infras

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

On Thu, Nov 24, 2016 at 10:34 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > > >1. it seems to me that, with this proposal, you move the burden of >implementing a rate limiting function from the domain owner to the >reporting organization. This seems not right to me, as

Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote: > Large email receivers forward tons of email. This proposal causes email > from DMARC-passing messages to be incapable of forwarding. As a large email > receiver who gets tons of complaints about breakage of DKIM signatures on > forwarded messa

Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

et me know what I've missed. -MSK On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy wrote: > On Mon, Nov 14, 2016 at 10:36 PM, wrote: > >> Let's break this down. If we're going to include recipients in the DKIM >> signature, it seems we have

Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin wrote: > 15.11.2016 2:07, Murray S. Kucherawy пишет: > > On Mon, Nov 14, 2016 at 10:36 PM, wrote: > >> Let's break this down. If we're going to include recipients in the DKIM >> signature, it seems we have at l

Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 10:36 PM, wrote: > Let's break this down. If we're going to include recipients in the DKIM > signature, it seems we have at least three key design decisions to make: > [...] > That's a pretty excellent summary. A couple of points: I think you narrowed it down to (0)(b),

Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

Hi Rolf, On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > At the time SenderID was proposed, back in 2004 or something, the act of > propagating header information into the transport stream was seen by many > as a layering violation. The proposal of Murra

Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote: > > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of recipient. > > Our default i

Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin wrote: > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form it > can not be implemented in most MTAs (see below) > 2. This standard mixes transport standards (S

Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 4:40 AM, Steven M Jones wrote: > So per Section 5, this form of DKIM signature will fail to verify at a > receiver who doesn't implement the new feature, period. And in fact any > forwarding - whether it alters the RFC5322 message or not - would > produce a DKIM verificati

[dmarc-ietf] draft-kucherawy-dmarc-rcpts

I've posted a draft that attempts to address an attack that's begun to appear with DKIM. Interestingly, we called it out as a possible attack in RFC6376 and even RFC4871, but now it's apparently happening and being annoying enough that people (I believe from the MAAWG community) are asking if ther

Re: [dmarc-ietf] Progress of ARC documents

On Wed, Oct 5, 2016 at 7:35 AM, Barry Leiba wrote: > Working group: > Have all of you reviewed the ARC documents? Does the dearth of > discussion of them mean they're close to ready? > I've been working on an open source implementation. It consists largely of re-purposed code pulled from my op

<    2   3   4   5   6   7   8   9   10   11   >