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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
