Re: Network security manager

[Lars Magne Ingebrigtsen]

Toke Høiland-Jørgensen <address@hidden> writes:

> 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...

You'd hope not.  If there is, that's not a good 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

DANE and especially revocation checking is kinda slow though?  Which is
why Chrome doesn't do it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no