Re: We define how, we don't dictate what

[Michael De Roover <[e-mail]>]

Hi,

I do acknowledge the IETF to be rather siloed, and I do acknowledge that 
security-sensitive issues require special care. However, I do not acknowledge 
that they should deviate from the usual practices for WGs, which is that if a 
WG exists for a subject, that's where it is discussed. For this issue, that is 
clearly TLS where both the contested draft, and thus also the discussion, are 
meant to be done. This list has participants from far too many different 
churches for all of them to be interested in this.

You mention that IETF is a siloed organization, which I acknowledge as IETF 
being perhaps not as large as it could be. You also mention that among the 
IETF, there are many people with very different interests. Some of those are 
interested in cryptography, others are interested in bringing the Internet to 
outer space. Fantastic.

But that also means that the person interested in protocols for space, is not 
necessarily interested in cryptography. It's only once that protocol actually 
needs to be encrypted (because, well, it's going over a long-distance wireless 
link), that cipher choice would become relevant. And even then there's still 
the question about threat models (where are the aliens with their wiretaps? 
Are we the aliens?) and hardware acceleration to get good performance out of 
it.

Now, for designing the circuits that do the hardware acceleration (e.g. AES-
NI, not aware of something similar for ARM), you would need a solid 
specification. I certainly don't want another Spectre / Meltdown in my chips. 
Or a checkm8 in an Apple chip (ok I do want that one), etc etc.

But with Spectre and Meltdown too, what was the actual impact? I still use 
those vulnerable chips as if nothing happened! There's a kernel patch, sure, 
and speculative execution can be disabled entirely, by (iirc) disabling 
hyperthreading. But why though? Who is exploiting this? What if I don't have 
malware on my computers to begin with? What if my edge nodes run vulnerable 
kernels because they've been booted for years with no reboots, and I just have 
my open ports only run services that go through a TCP stream in NGINX? Would 
you be able to get kernel access to those servers? Try it and let me know!

Anyway, that's what I mean with "this belongs on TLS". Security is far 
overhyped for the most part, and many people -- even those in IT in general -- 
don't always know how to make a proper threat model. Yet everyone wants the 
Internet to be secure, which, yeah wonderful. But if you can't do that without 
establishing a threat model, then please let the people who do know how to do 
that, do their job! And if the protocol sucks for an, I would argue, far off 
quantum microcontroller for a chip, fix it when it actually does become an 
issue?

I'm not trying to be an ass here, even though I will most certainly be 
perceived by some to be one. But for heaven's sake, this does not belong here! 
If I were to be a conspiracist and ask myself why this is brought here, I 
would argue that it's because this is one of Daniel's fortes, and just like 
the MODPOD disaster ("dragnet censorship"), it can be brought in a very 
dramatic way. But hey, that's just conspiracy. Interpret it as you will, but I 
don't consider this to have been done in good faith.

On Sunday, 19 October 2025 15:33:30 Central European Summer Time Lloyd W 
wrote:
> hi Bron,
> 
> This wasn't mandating stuff on a different layer, this was mandating mention
> of and homage to security, which just happened to require a Best Practice
> Security Approach at a layer different from and irrelevant to the focus of
> the document.
> 
> As the IETF becomes increasingly siloed, with separate offlist ticket
> discussions happening in the safe spaces of github trackers, where
> cross-domain expertise is winnowed out n the interests of topic focus,
> security remains the one remaining excuse to go anywhere and Express
> Concerns, regardless of use cases or (lack of) relevant domain expertise.
> 
> I still pay attention to various space-related groups, where people
> enthusiastic about and a little knowledgeable about space implementations
> and architectures are required to pay attention to people enthusiastic
> about security.
> 
> So, instead of discussing, say, interoperability with Mars and how that
> might actually be made to work, a list is instead discussing e.g. making
> sure perfect forward secrecy can be done, or trying to make everything work
> with QUIC, because QUIC is the current secure transport of choice. Every
> discussion becomes a security discussion.
> 
> And the thing about security is, when it fails, it deliberately fails hard.
> Having to implement key expiry on something that didn't even need it?
> you're implementing your own denial of service on yourself, and when it
> fails a few light-hours out usual recovery strategies won't work. But the
> denial of service was really expressed way back when  on a wg list by some
> security maven saying 'we need keying. and expiry, of course.'.
> 
> Focusing on security did not play out well imo for DTN or the Bundle
> Protocol, and this is more of the same.
> 
> The current IETF orthodoxy is to show that security  has been paid its dues
> before anything can be published, and this now goes far beyond a mere
> Security Considerations section.  If paying those dues compromises
> everything else in a design, so be it. The security experts are unlikely to
> notice, or care; that is not their concern.
> 
> Security IS now the Protocol (Thought) Police,  RFC 8962 notwithstanding.
> 
> Lloyd Wood
> [e-mail]
> 
> they who control the draft control the RFC.
> they who control security control design.
> they who control design control the draft.
> 
> > On 18 Oct 2025, at 04:00, Bron Gondwana
> > <brong=[e-mail]> wrote:
> > 
> > Between core-06 and core-07 the TLS language was added.  There was plenty
> > of debate over the pros and cons in person and on the lists - and the
> > authors wound up bowing to IETF orthodoxy.
> > 
> > In my opinion JMAP core shouldn't require "https" particularly, it could
> > be transported over some other substrate just fine.  At most, it should
> > point to some other spec which provides "best practices for using HTTP
> > transports securely" and say use that, or updates to it.
> > 
> > This wasn't an "influence", this was "the IETF won't publish anything
> > which doesn't mandate these things on a different layer".  I don't think
> > we should be doing that.


-- 
[Met vriendelijke groet] [Best regards]
[Michael De Roover]
---      ---      ---      ---      
[Mail] [*@nixmagic.com] [michael@[e-mail]]
[Web] [https://michael.de.roover.eu.org]
[Forge] [https://git.nixmagic.com]
[Weather] [Antwerpen] [20:00] [12.4°C]
---      ---      ---      ---      
[0] [2025-10-19 20:12 CEST]
[~] [[e-mail]]
[$] [/usr/bin/sign-mail] [>_] 
---      ---      ---      ---