Re: Network security manager

[Toke Høiland-Jørgensen]

Ted Zlatanov <address@hidden> writes:

> * uses SSH-style gnutls_store_pubkey() and gnutls_verify_stored_pubkey()
>   to DTRT and pins the public key rather than the certificate
>   fingerprint. The pub keys are stored by default in a way that lets the
>   user look them up by hostname, but we can customize that. And it's
>   mostly handled by GnuTLS internals as far as pubkey extraction and
>   verification.

AFAICT this is functionally equivalent to what is currently in NSM;
except it stores the public key rather than the fingerprint. I am not
sure if there area any security implications to storing just the
fingerprint...

> * does DANE auth (although I don't know the details on DANE, the
>   client implementation looks reasonable and Toke suggested it)

I think the right thing to do would probably be to check DANE and use
that as an additional input to the NSM dialog. I'd suggest the
following:

- Supply the DANE status as part of the 'certificate information' blurb
  when popping up a prompt. For many (most?) setups this will be
  'unknown' either because no DANE info is published in DNS or DNSSEC
  validation fails (or both).

- If valid DANE info is available *and* this doesn't match the shown
  certificate, treat it as a reason to consider the certificate
  insecure.

I.e. treat a positive DANE verification as information to present to the
user, and a verified failure as a cause for alarm. This corresponds to
the current DANE RFC recommendations AFAICT...

> * checks OCSP for revocations using cert_verify_ocsp() in the same
> cli.c

This would probably be a good idea to implement in any case.

-Toke