On Mon, Mar 23, 2026 at 5:56 PM Nico Williams <[email protected]> wrote:
>
> On Mon, Mar 23, 2026 at 03:18:40PM -0400, Jeffrey Walton wrote:
> > On Mon, Mar 23, 2026 at 3:01 PM Alan DeKok
> > <[email protected]@dmarc.ietf.org> wrote:
> > > Where can I get a certificate for mail.example.com <
> > > http://mail.example.com/> that is (a) trusted by end-user systems, and
> > > (b) is limited to id-kp-This-Is-A-Mail-Server?
> > >
> > > What happens now is one of 3 things:
> > >
> > > 1) use a web cert, and lie to the CA/B forum about what you're using it
> > > for. This (allegedly) means that they can revoke it at any point for
> > > mis-use
> > >
> > > 2) use a private CA, and have everyone else on the Internet refuse to talk
> > > to you, as your CA is unknown
> > >
> > > 3) don't use TLS.
>
> The best answer for SMTP is DANE, and if need be run a private CA or
> self-sign the EE certs.
>
> > Regarding Item (2), wouldn't Trust on First Use (TOFU) work well?
>
> No. Not at all.
>
> First of all: no, because that's not strong enough.
>
> Second of all: how do you rotate keys? (you couldn't unless it's not
> TOFU but trust-always-no-matter-what, which is not what you want because
> see the first point :)
One small disagreement here.
I'll take TOFU and certificate pinning over conferring trust to a
third party like a CA. TOFU and pinning have not failed me once in my
years of SSH use. But you are correct -- there does need to be a way
to update pinsets or rotate keys on occasion. And it is worth
mentioning an organization that has a priori knowledge of a {hostname,
public key}-tuple (like with an in-house app) does not need TOFU.
They can move directly on to pinning.
I value key continuity over key rotation. I find key continuity is a
much more valuable security property than gratuitous key material
rotations based on astrological charts.
I find short lived certificates an abomination. OCSP stapling already
solves the problem of large CRLs and offline CRLs. Shame on Let's
Encrypt for introducing that obscenity.[0]
[0] <https://letsencrypt.org/2024/12/11/eoy-letter-2024>
> > [...]
> >
> > And who needs a CA anyways? All we need is a hostname and a public key.
> > We don't need a CA to bind them. The hostname and public key information
> > is presented in an end-entity certificate, so that's all we need. The
> > self-signed certificate can be hosted in DNS and retrieved as required
> > since that seems to be the modern equivalent to the X.500 directory. The
> > world does not need to be adverse to self-signed certificates just because
> > the CA/BF does not care for them.
>
> Yes, but only if you're using DNSSEC. Then DNSSEC becomes _the PKI_ --
> the one and only PKI, though, well, you can have alternate roots of
> course, so it's not that singular a PKI, but for every RP it _is_
> singular indeed.
>
> I think that's the argument you're hinting at, and if so I'm in violent
> agreement. But you'll notice that DANE has not made much headway
> outside of SMTP (where it's made plenty, largely thanks to Viktor's
> efforts).
One other thing I'll add... Web apps are relegated to handling low
value data because of the lack of security controls we can place, and
some of the decisions the browser engineers have made. If you want an
app that can handle medium and high value data, then you have to write
a hybrid or native app. Native apps allow one to do things like
public key pinning, so apps have assurances about the secure channel
and secure storage.
The consummate example I give is an organization's Self-Service
Password Reset app. Do you really want your employees passwords
compromised by a TLS interception box (possibly from an external
organization) because TLS as implemented in a browser cannot provide a
secure channel? Typically an organization has a policy in place that
says a compromised password has to be reset and rotated. But changing
a password using a web app in this instance leads to another
compromised password. Ad Infinitum. The only way off the hamster
wheel is a native app that enforces a secure channel.
Too many CTO's have drunk the web app kool aid.
Jeff
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
