4 ms·

It's a touch odd to make a big deal of the fact that you've filed a complaint and fail to mention that it was formally rejected three days before you published

by mjg59 1y ago

It's a touch odd to make a big deal of the fact that you've filed a complaint and fail to mention that it was formally rejected three days before you published the post: https://datatracker.ietf.org/group/iesg/appeals/artifact/146 https://datatracker.ietf.org/group/iesg/appeals/artifact/146

fn-mote 1y ago
Lots of respect to both you and the author, but the rejection gives no real response to any of the issues I see raised in the document. It failed to raise my confidence at all. > The IESG has concluded that there were no process failures by the SEC ADs. The IESG declines to directly address the complaint on the TLS WG document adoption matter. Instead, the appellant should refile their complaint with the SEC ADs in a manner which conforms to specified process.
- mjg59 1y ago
  I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.
  - timschmidt 1y ago
    Having served on boards, rejections on procedural grounds which fail to address engineering concerns which have been raised stink of a cop-out.
    - mjg59 1y ago
      Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
      - timschmidt 1y ago
        > Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.
        mjg59 1y ago
        There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.
        timschmidt 1y ago
        > and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've read and linked to.
        mjg59 1y ago
        As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was raised to the IESG, who are not the point of contact for engineering issues, the response is focused on that. There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.
        timschmidt 1y ago
        > There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise I wouldn't be aware of these dangerous developments. Excuses of any kind ring hollow in the presence of historical context around NSA and encryption standardization, and the engineering realities.
EasyMark 1y ago
It's still nice that it was put up for completeness. And as we know this stuff has a long sordid history of people who are proponents of weakening encryption not giving up easily.

by mjg59 1y ago

fn-mote 1y ago

Lots of respect to both you and the author, but the rejection gives no real response to any of the issues I see raised in the document. It failed to raise my confidence at all. > The IESG has concluded that there were no process failures by the SEC ADs. The IESG declines to directly address the complaint on the TLS WG document adoption matter. Instead, the appellant should refile their complaint with the SEC ADs in a manner which conforms to specified process.

mjg59 1y ago
I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.
- timschmidt 1y ago
  Having served on boards, rejections on procedural grounds which fail to address engineering concerns which have been raised stink of a cop-out.
  - mjg59 1y ago
    Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
    - timschmidt 1y ago
      > Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.
      - mjg59 1y ago
        There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.
        timschmidt 1y ago
        > and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've read and linked to.
        mjg59 1y ago
        As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was raised to the IESG, who are not the point of contact for engineering issues, the response is focused on that. There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.
        timschmidt 1y ago
        > There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise I wouldn't be aware of these dangerous developments. Excuses of any kind ring hollow in the presence of historical context around NSA and encryption standardization, and the engineering realities.

EasyMark 1y ago

It's still nice that it was put up for completeness. And as we know this stuff has a long sordid history of people who are proponents of weakening encryption not giving up easily.