Hi Viktor, Thanks for writing up your thoughts; a couple notes inline:
On Tue, Jul 17, 2018 at 10:30:39PM -0400, Viktor Dukhovni wrote: > > Below I shall try to address a few of the concerns raised in writing. > You can read just the high-level notes above my signature, diving > into the corresponding detailed exposition below my signature as > you see fit. Apologies for lack of hypertext links. > > 0. The draft as approved by the IESG, describes unilateral pinning > by the client. We all agree that was not a good idea, but it > was a well-intended attempt to address a real security gap. > > 1. The hypothetical "assertive use-case" Richard mentions that is I think that the use of the shorthand terms "assertive" and "restrictive" for use cases is only causing confusion at this point, not least because it could apply both to the TLSA Certificate Usage values and to whether DANE is treated as less trusted, equally trusted, or more trusted than PKIX. If I remember the detailed discussion below correctly, you refer to the case of "DANE is equally trusted as PKIX", for which the analysis of "all the costs of both with no benefits" is a tolerable summary. > based on just the current draft is a non-starter. [ Sadly, Paul > forgot to disabuse the audience of its possibility on Monday ] > > If the WebPKI is presumed never compromised then we don't need > a DANE alternative. With the present draft, DANE offers no > protection when the WebPKI is compromised. > > 2. Denial of existence reached consensus on list shortly after > London, we just need to polish up the text. It is also quite > useful for the greenfield applications that can make do without > pinning. I was surprised to hear some suggest that denial of > existence remains outside the WG consensus. I would also be surprised to hear such suggestions; text on denial of existence is already staged in github and is just waiting on a decision to publish a new draft. (Which is, I presume, waiting for an indication of whether we're likely to gain consensus soon on any other issues that could be addressed in the same update.) -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
