On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla <e...@rtfm.com> wrote: > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. > > (I've mentioned this in private email to some of you, but for broader input, I'm throwing it out on the list too.)
On the topic of other layers .. At yesterday's WG meeting, Sam Weiler suggested that the pinning information could be conveyed via the DNS. That way you would not need new holes/fields in the TLS extension. Paul said it doesn't work. But Willem Toorop and I discussed it after the meeting, and think that it does. There could be a new DANEPIN RR type at the same TLSA record name (or TXT if we're opposed to new types) that could carry the pinning TTL and whatever else. This could be conveyed as just an additional record (and its signature) in the dnssec_chain extension data (which is designed as a sequence of RRsets), and authenticated in the same manner. It is of course vulnerable to stripping on first contact, but so is the entire TLS extension including any pinning fields, in the incremental deployment scenario. So it has no worse or better security properties. This could also express a generic DANE pinning capability that is not tied only to a TLS channel. Servers that don't want to be pinned would not advertise this record, and clients that don't implement pinning would just ignore this record if it is present in the chain. (It is probably possible to convey this DNS info in other ways, such as defining a new TLSA record usage field for pinning. So the TLSA RRset would include an additional record for pinning if needed. But I suspect there might be more arguments about such a design). This does need the dnssec_chain extension to allow authenticated denial chains to be delivered. Based on past list discussion, it appears to me that there is rough consensus to allow that, and the yet unpublished draft text in the github repo already includes it. Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
