On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote: > On Mon, 16 Apr 2018, Viktor Dukhovni wrote: > >>* We might want to say that if the TTL is zero then the clients MUST NOT > >> pin and must clear any pin. And we might do this in spite of not > >> describing any pinning semantics -- explicitly leaving pinning > >> semantics to a future document. > > > >Exactly. I'd like to suggest that this is the most reasonable > >common ground, and would urge the WG and authors to get behind > >this as a consensus position. > > This seems dangerous. If an attacker can re-route and get a rogue > cert, they can set TTL to 0, negating a previously set TTL, without > requiring proof by presenting the denial-of-existence of the TLSA > record. That is also a downgrade attack.
The extension would have to be present and contain either the TLSA RRs and chain, OR the denial of existence chain, in order to even to carry any TTL value. Only in the denial of existence case could an impersonator set a TTL value of the impersonator's choice, and in this case the client must treat it as zero in order to avoid a DoS. In the other case, the impersonator could *not* set a TTL of their choice without compromising DNSSEC. > How to go from TTL != 0 to TTL == 0 should be specified carefully, > either in this document or its own document. If the server sends a denial of existence, then the TTL can't be fully trusted, and there is a DoS if the client uses non-zero TTL values. If the server sends TLSA RRs and chain then all TTL values can be trusted and should be used, though we might specify how in a later document. > The only known save way of going to TTL == 0 is by presenting DoE of > TLSA records (but it does bind using the TLS extension to the existence > of TLSA records) The TTL will be coerced zero on DoE, but it can be set to zero in the TLSA case as well. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
