Allow submissions from secondary emails

[ietf-svn-bot]

resolution_fixed type_defect | by mt@lowentropy.net

---

The datatracker blocks submissions from secondary emails. Henrik and I have discussed this in the past, but I've at least two cases now (see martinthomson/i-d-template#172 for the second).

The original reason for rejecting my request to fix this was denial of service, but I can't connect this feature with any increased risk of DoS.

---

Issue migrated from trac:2639 at 2022-03-04 07:04:03 +0000

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Your statement of the reason for not doing this (DoS) is incorrect.

The concern I have is fraudulent posting of -00 drafts, akin to wiki spam. It is already possible through the datatracker submission API today because it accepts unauthenticated posting from any datatracker login, but the email confirmation roundtrip makes this of limited concern.

Widening the possible posting addresses from logins to all email addresses will widen that attack surface substantially, as there is much larger likelihood that people don't have control of all their old email addresses than that they don't have control of the email address matching their login.

I have in the past proposed the use of per-user or per-document API keys in order to make things more secure and open up the possibility of easing some of the current restrictions, and you've rejected that path.

[ietf-svn-bot]

@mt@lowentropy.net commented

---

Thanks for clarifying that Henrik.

I don't see how this makes spamming worse. If you rate limit on a per-account basis, that is.

[ietf-svn-bot]

@mnot@mnot.net commented

---

I agree with Martin's assessment. As a WG chair, this is causing serious problems for our authors; please reconsider.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

To reconsider, new data is needed. Can you provide a few concrete examples where this has caused serious problems, please? That will hopefully provide more data which may show a way forward.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

And FWIW, please again consider if this cannot be more securely solved by permitting access through per-document API keys.

[ietf-svn-bot]

@mnot@mnot.net commented

---

Well, the new data is that you have more working group chairs and authors who are unhappy with the current functioning of the system, surely?

Both I and other authors have had issues with submitting using Martin's toolchain, due to this issue. It requires fallback to manual processing which is time consuming and more error prone, and can put us at risk of missing submission deadlines.

Per-document API keys, as I understand it, would require much more coordination; someone with administrative access to the repo (probably the WG chair) would have to obtain the API key (somehow) and put it into the CI environment, and assure that it applied to the correct document. That seems like a lot of manual setup, which again is onerous and error-prone.

Like Martin, I don't see significant exposure, so long as account-level limits are in place. Perhaps you could explain your concern more fully? I.e., what's the exact attack scenario you're concerned about, and what about it increases the attack surface area (as compared with the current deployment)?

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Replying to ietf-svn-conversion/datatracker#2639 (comment:6):

Well, the new data is that you have more working group chairs and authors who are unhappy with the current functioning of the system, surely?

No Mark, that isn't new data, that's adding pressure to bear to make us do something that wasn't safe with the old data.

I deeply resent this approach at making things happen. Please provide new data so this can be resolved by added understanding, not by pressure.

Both I and other authors have had issues with submitting using Martin's toolchain, due to this issue. It requires fallback to manual processing which is time consuming and more error prone, and can put us at risk of missing submission deadlines.

I still don't understand why using the primary address is such a pain, so will you please provide new data. Specific, detailed new data. Not trying to pressure an unsafe solution into existence.

Per-document API keys, as I understand it, would require much more coordination; someone with administrative access to the repo (probably the WG chair) would have to obtain the API key (somehow) and put it into the CI environment, and assure that it applied to the correct document. That seems like a lot of manual setup, which again is onerous and error-prone.

I don't see that per-document API keys would require more effort to update the repo than adding text to a document by an author would. Any author or a document could get the key from the datatracker, and any author could add a suitably named file to the repo and push it (or do a pull request, if that's how the workflow is set up). With document-specific API keys there's no requirement to keep the key secret. It would not require action by anybody but one of the authors, who (I sincerely hope) can already commit and push updates (or pull requests) against the document.

Like Martin, I don't see significant exposure, so long as account-level limits are in place. Perhaps you could explain your concern more fully? I.e., what's the exact attack scenario you're concerned about, and what about it increases the attack surface area (as compared with the current deployment)?

Limits will not make it so an old email address not under the control of an IETFer any more can't submit fake spammy drafts. It will prevent it from happening more than say 5 times per day (assuming a limit of 5) -- I don't really want any spammy drafts autosubmitted at all. Limits isn't a protection against annoying draft spam, it's a mitigation after the annoyance has happened.

If you provide specific data that is sufficiently concrete and detailed that they add understanding and make it possible to think about solutions, there may be a way forward. Without it, no.

[ietf-svn-bot]

@rjsparks@nostrum.com changed status from new to accepted

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

There has been quite a bit of direct email discussion of this ticket. One result is that we will implement accepting Submissions for a draft where the email identity asserted is an Active email address in the datatracker's Email table.

[ietf-svn-bot]

@rjsparks@nostrum.com changed priority from n/a to medium

[ietf-svn-bot]

@henrik@levkowetz.com changed status from accepted to closed

[ietf-svn-bot]

@henrik@levkowetz.com changed resolution from `` to fixed

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Fixed in b4d7dd1:

Added ability to use the submission API with active secondary email addresses. Fixes issue #2639.