On Sun, Sep 17, 2017 at 11:04:47PM +0200, martin f krafft wrote:
> > I think you're saying your organization places machines you
> > (collectively) build on other people's networks, but the machines
> > need to send call home to send email, which is sometimes outbound
> > to other domains?
>
> I'll go with that.
>
> > How does one of these far-flug clients get an LE certificate in
> > your domain in the first place?
>
> We control the DNS infrastructure centrally in all cases (using
> DNSSEC, of course), and so we issue them centrally. They are
> currently deployed over SSH tunnels to the hosts.
So your certral system generates the keys, and obtains the LE
certificates on behalf of the far-flung hosts? And then pushes
these keys to the hosts over an SSH tunnel?
Is that only for the initial key issuance? And then each host
rotates the certs independently of the central system using the
existing key to authenticate to LE?
I am curious why you want to rotate the submission TLS client keys.
If you are able to centrally push keys to the hosts, why bother
with a CA at all? Why not generate a self-signed key+cert, store
the fingerprint in a database, and leave LE out of it? The key
would not change for the lifetime of the host.
> > I am trying to understand why you want to delegate relay control
> > decisions for your domain to LE.
>
> It's a valid question, for sure. But I wouldn't say we delegate
> relay control decisions to LE per se. Of course they'd become part
> of the equation and could abuse it, but that'd be the end of their
> story, too.
Well, any certificate they issue in the future for your domain
becomes valid for relay host access. It seems rather permissive.
Sure the domain is yours, and perhaps you trust all the variants
of their challenge protocol (including plain old email to
admin@, postmaster@, ...), but it seems overkill in this case
to open yourself up to this...
> > Well, it isn't typically "just as safe", the LE enrollment process
> > is often vulnerable to on-path or BGP-route forgery MiTM attacks
> > between the CA and the domain for which the certificates are being
> > issued.
>
> DNSSEC does address this somewhat.
DNSSEC helps with having CAA records that are difficult to MiTM,
and protectst the DNS challenge protocol, but I don't whether it
is possible to disable bootstrapping over weaker email challenges
and/or control over port 80.
> Apart, the current way by which Postfix uses cert fingerprints is
> just as vulnerable to those kinds of attacks, no?
No, not at all. If you provision the fingerprints over a secure
channel they are quite safe from active attacks.
> Thanks for your challenging questions. I'm well aware that this
> isn't exactly postfix-users material, but it's helping me
> tremendously, and I hope others also find this interesting. I do
> hope Postfix will benefit from this long-term, by way of docs, or
> something like check_certname_access or whatever we come up with.
The reason I am asking them is not because I've decided to not
implement access by subject name (though given the SAN situation,
and the potentially large number of SANs to test, the feature is
tricky to implement fully and correctly). Rather, understanding
the use cases that motivate feature requests help us figure out
whether we're building the right and sufficiently general feature.
I should also note that with LE and certbot's "--csr" option you
can renew LE certificates *without* changing the public key. In
which case the public key fingerprint is stable, and need not
change.
--
Viktor.
