On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote: > Sorry for being confusing. I meant to say full Denial of Existing is in > the draft implicitly already (because of the reference to DANE > authentication according to RFC6698 and RFC7671 (which do mention it) in > Section 6). > > > I do like the idea of STS for this extension (and augment it with the > more restrictive DANE use cases), but I'm unsure about the security of a > built-in version. > > I notice that existing STS documents (HSTS [RFC6797] and MTA-STS > [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL > conveyed in a ServerHello message secure when it would be just for SSL?
One has to wait for the handshake to complete for most cases (basically all except the "clear pins with DoE" case). > I can see this might be different for the DANE use case because of the > signed statements that come alongside the TTL, but for example... > In case of built-in STS with the extension, what does a 0 TTL mean? > > - When 0 has been the only value seen ever, it is clear to me that the > mechanism is equivalent with what we have in the draft now, but.. > > - When another value has been seen before, is a value of 0 then enough > to clear the pin? Or would a DoE proof (or insecurity proof) > alongside it be necessary? The way I understand it would work, it would clear the pin at end of handshake (one could clear immediately on DoE, but maybe better to delay that too). > In case of the latter, what does that mean for sites that do have > DANE records, but no servers that support the extension? Can they > be hampered (for an indefinite period) by a MiTM? That would be > really bad for DANE deployment. That type of attack is possible in some scenarios: - The DANE records pin a CA and MITM can get misissued certificate from that CA. - The server private keys get stolen. Since the MITM would need to present a key that exists in the DANE records in order to actually activate this pinning. Recovery would need deploying the extension (the data needed is public in DNS). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
