On Wed, 18 Jul 2018, Eric Rescorla wrote:
detailed response to concerns raised in the room on MondayOn Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: c. Testing is not a good fit at this layer, all that's pinned is the ability to deliver the extension, after a previous connection delivered DANE TLSA records and a non-zero extension support lifetime. There is no TLS-layer mechanism for the client to inform servers that don't offer the extension that this extension was expected while continuing the connection. The closest we get is the TLS 1.3 missing_extension(109) alert, which does not carry the id of the mission extension, and is a failure alert. Out-of-band notification would require HTTP support in applications that can't generally be expected to include an HTTP implementation. To the extent to which this is true, it's an argument that one should be pinning at a different layer.
Those clients with clean DNS transport, like mail servers, already use the TLSA records the moment these appear in DNS. The zone owner already fully commited the service to this, regardless of what you do at other layers. So you are already commited to the DATA in DNS. Each transport has their own properties and we found that pinning the TLS extension is needed when using TLS stappling. It is a property of the transport lawyer, so anything about that transport layer should not happen elsewhere. Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
