> On May 16, 2018, at 12:20 PM, Tom Ritter <t...@ritter.vg> wrote:
>
> On the balance, I support adding the two bytes.
Thanks for responding, and sorry to frame the request as "please
support", I've previously tried to careful and ask people to
respond with their comments whatever they might be, and should
have done so this time too.
> I would argue that the top-most or bottom-most bit should be used as a
> testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a
> second draft) specifying the policy should add a generic
> problem-reporting extension that allows one to post a description of
> errors encountered. But these arguments do not hinge my support of two
> bytes.
For the record, the reason that we're confident that two bytes are
enough is that DNS TTLs already take care of sub-hour continuity
for any provided TLSA records. So units of hours are natural, and
make 16 bits quite sufficient.
We've given the need for other pinning properties from other STS-like
protocols some thought, and it turns out that none apply. IN particular
a testing mode is not possible with this extension. Such a testing mode
would itself be a downgrade attack. Any testing mode for DANE would
have to be specified as a new element type for the TLSA RRset to be
authenticated via DNSSEC, not as a WebPKI-authenticated element of this
extension.
The extension is a channel to deliver security-relevant data
from DNS, and the pin when specified, would just pin support
to continue to provide the channel. The STS-analogy is the
closest available but it is not a faithful one, the requirements
here are much simpler.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
