Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Paul Wouters <[e-mail]>]

On Mon, 25 Jun 2018, Joseph Salowey wrote:

> There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. 
>  I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for
> modifications in the revision.  Please respond to the following questions on the list by July 10, 2018. 
> 
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another
> approach)?

Yes I support taking on the work to do the extension pinning. Just to
ensure people are not confused, this is not about pinning of TLS(A) data.

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

Yes I support both this proposal of reserved bytes or the previous the two
byte reservation. I have no strong preference.

I do not support using a second TLS extension to pin the first, or the
use of a TLS Extensions block, which is also basically two extensions
interacting with each other.

> 3.  Do you support the proof of denial of existence text in the revision?

Yes I support this text, provided the error in the example.com example is
fixed (it is using the wrong NSEC record, see Viktor's or my PR for the
fix)

> 4.  Do you support the new and improved security considerations? 

Yes I support the changes.

Do note that this part confuses me a little bit:

 	but under the assumptions of this specification, there may not be a
 	reliable way to obtain such DNS records.

where "such" refers to Denial of Existence records. Since your change
also has:

+        Following the TLSA or denial of existence RRset,
+        the subsequent RRsets MUST contain the full set of DNS records
          needed to authenticate the TLSA record set or denial of existence
          response via the server's trust anchor.

I think the "there may not be a reliable way to obtain such DNS records."
can be removed?

Paul