(VB from comment #4) > Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA). I explicitly did not suggest that. TLSA should definitely not be used as trust anchor as it would circumvent certificate transparency. Demanding it would likely cause wontfixing this bug. Using TLSA like HPKP is the least invasive and most safe change. While CAA is just a wish, TLSA would allow a domain to pin to Let's Encrypt (or to leaf certificates) while enforcing https. It should be fetched the moment the connection is established and initially have an enforced maximum TTL of 1 day, for example. > For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage 2 as 0 => let a domain pin itself to let's encrypt (like HPKP. Do not use it as non-WebPKI trust anchor.) 3 as 1 => let a domain pin its leaf ceritifcates (like HPKP)
Bug 1450674 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(VB from comment #4) > Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA). I explicitly did not suggest that. TLSA should definitely not be used as trust anchor as it would circumvent certificate transparency. Demanding it would likely cause wontfixing this bug. Using TLSA like HPKP is the least invasive and most safe change. While CAA is just a wish, TLSA would allow a domain to pin to Let's Encrypt (or to leaf certificates) while enforcing https. It should be fetched the moment the connection is established and initially have an enforced maximum TTL of 1 day, for example. Or don't cache it at all. > For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage 2 as 0 => let a domain pin itself to let's encrypt (like HPKP. Do not use it as non-WebPKI trust anchor.) 3 as 1 => let a domain pin its leaf ceritifcates (like HPKP) Selector: Do not support 0 (the whole certificate: ignore it, just enforce https), only support 1 (public key). Matching type: Do not support 0 (the whole public key: ignore it, just enforce https), only support 1 (SHA256) and 2 (SHA512).
(VB from comment #4) > Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA). I explicitly did not suggest that. TLSA should definitely not be used as trust anchor as it would circumvent certificate transparency. Demanding it would likely cause wontfixing this bug. Using TLSA like HPKP is the least invasive and most safe change. While CAA is just a wish, TLSA would allow a domain to pin to Let's Encrypt (or to leaf certificates) while enforcing https. It should be fetched the moment the connection is established and initially have an enforced maximum TTL of 1 day, for example. Or don't cache it at all. > For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage 2 as 0 => let a domain pin itself to let's encrypt (like HPKP. Do not use it as non-WebPKI trust anchor.) 3 as 1 => let a domain pin its leaf ceritifcates (like HPKP) Selector: Do not support 0 (the whole certificate: ignore it), only support 1 (public key). Matching type: Do not support 0 (the whole public key: ignore it), only support 1 (SHA256) and 2 (SHA512).
(VB from comment #4) > Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA). I explicitly did not suggest that. TLSA should definitely not be used as trust anchor as it would circumvent certificate transparency. Demanding it would likely cause wontfixing this bug. Using TLSA like HPKP is the least invasive and most safe change. While CAA is just a wish, TLSA would allow a domain to pin to Let's Encrypt (or to leaf certificates) while enforcing https. It should be fetched the moment the connection is established and initially have an enforced maximum TTL of 1 day, for example. Or don't cache it at all. > For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage 2 as 0 => let a domain pin itself to let's encrypt (like HPKP. Do not use it as non-WebPKI trust anchor.) 3 as 1 => let a domain pin its leaf ceritifcates (like HPKP) Selector: Do not support 0 (certificate: ignore it), only support 1 (public key). Matching type: Do not support 0 (the whole public key: ignore it), only support 1 (SHA256) and 2 (SHA512).