[gnutls-help] GnuTLS with TOFU verifies public keys, not certificates

[Daniel Kahn Gillmor]

On 04/17/2014 01:33 PM, Jens Lechtenboerger wrote:

> One of my e-mail providers changed an IMAP certificate, and
> mail-notification warned me about the new certificate with an
> unknown fingerprint.  Both certificates are issued by different CAs.
> 
> Surprisingly, though, gnutls-cli with option --tofu did not complain
> at all (same for --strict-tofu).
> 
> It turns out that both certificates contain the same public key.
> (Why would somebody do this?)

presumably they did this because they have a key that they do not think
has been compromised, but their certificate expired.

> As gnutls-cli stores only the public key in ~/.gnutls/known_hosts,
> but nothing about the certificate, it cannot detect any difference.
> I don’t see any security issue here,

I agree that there is no security issue.  Using TOFU *should* use the
public key, not the certificate; otherwise, it's guaranteed to fail when
the certificate expires, which seems kind of pointless for a
key-continuity-based approach like TOFU.

> but I suggest to extend the
> documentation, in particular, the man page of gnutls-cli:
> 
> For --tofu, currently “in addition to certificate authentication”:
> This should probably read “instead of certificate authentication.”

I agree that this change in documentation would match the current
behavior.  I'm wondering, though, whether we want to change the behavior
to match the documentation.   Both --tofu and --dane say "in addition to
certificate authentication", but only --dane seems to accept standard
X.509 certificate authentication as well.

even using "gnutls-cli --ca-verification --tofu www.example.org" doesn't
use certificate verification.

> Afterwards emphasize: “Note that public keys are recorded, not
> certificates.”
> 
> For --strict-tofu: “certificate” needs to be replaced with “public
> key” twice.


The above changes seem reasonable to me.

> Alternatively, should ~/.gnutls/known_hosts also store the
> certificate’s fingerprint to detect such changes?

i don't think this is a good idea.  what would the benefit be?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140417/fefc9b44/attachment-0001.sig>