Re: wget2 | New option --dane (!522)

[Viktor Dukhovni (@dviktor)]

Viktor Dukhovni commented on a discussion: 
https://gitlab.com/gnuwget/wget2/-/merge_requests/522#note_1373400293

Thanks for the overview.  The key thing to decide now is which deployment 
models to implement.

* Support hardening of WebPKI via DNSSEC-validated DANE TLSA records:
    - When DANE TLSA lookups fail (SERVFAIL, timeout, BOGUS, ...) validation 
fails.  Otherwise, any such "hardening" is trivially downgradable by blocking 
access to the TLSA records.
    - Only PKIX-TA(0) and PKIX-EE(1) certificate usages are supported 
(considered *usable* per RFC6698) in this case.  TLSA record with other 
certificate usages are ignored.
    - When *usable* DNSSEC-validated TLSA records are present, they are also 
required to match the presented certificate chain.
    - WebPKI validation must still pass unconditionally.
    - At least one TLSA record must match the certificate chain (EE cert or 
some issuing CA).
    - This means you are protected by WebPKI or DANE whichever is stronger.
    - Downside: connections fail when either is poorly managed (though e.g. 
certificate expiration can break both, ...).
* Support a DANE-only mode, no WebPKI:
    - TLSA record lookups MUST succeed and be DNSSEC-validated
    - The only certificate usages that are accepted (*usable*) are just 
DANE-TA(2) and DANE-EE(3).
    - At least one of these must match the certificate chain.
    - Note that with DANE-TA(2) the chain must still be validated relative to 
the supplied trust-anchor (checking expiration dates of issued certificates, 
signatures, ...).  This is very similar to WebPKI, just with a remotely 
supplied trust anchor and no need for cruft like CRLs, OCSP, ...
* Support an opportunistic DANE mode:
    - When DANE TLSA lookups fail (SERVFAIL, timeout, BOGUS, ...) validation 
fails.  Otherwise, this is trivially downgradable by blocking access to the 
TLSA records.
    - When no DNSSEC-validated records are published (NXDOMAIN or NODATA or 
records are from a non-DNSSEC delegated zone or via a partly unsigned CNAME 
chain, ...) proceed with WebPKI as usual.
    - When records are DANE-TA(2) or DANE-EE(3) use only DANE.
    - When they are PKIX-TA(0) or PKIX-EE(1) perhaps do both WebPKI and DANE, 
*but*, note that this is still only as strong as the domain's DNSSEC security, 
because an attacker who can compromise DNS can change the certificate usages.
    - Therefore, I don't find "opportunistic" use of PKIX-TA(0) or PKIX-EE(1) 
particularly compelling.
    - In SMTP opportunistic DANE TLS only the DANE-?? usages [are 
supported](https://datatracker.ietf.org/doc/html/rfc7672#section-1.3).

The user would typically have to indicate which mode they want.  The `--dane` 
flag could default to one of the modes, with the others requiring a separate 
signal of intent.

Care is required to avoid downgrade attacks (DNS lookup failures must be hard 
errors).  Care is also required to implement DANE-TA(2) correctly, though 
ideally this is done by the TLS library, past naïve independent implementations 
of chain validation have been often buggy.

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.com/gnuwget/wget2/-/merge_requests/522#note_1373400293
You're receiving this email because of your account on gitlab.com.