> On May 3, 2018, at 8:54 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
>
> (2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority
> that the 16-bit value (in hours) is sufficient, and no other fields or
> semantic changes would be needed. While I (and presumably others) do have
> a great deal of confidence in your collective technical expertise, it still
> seems to be presumptuous and a coopting of the WG consensus process for the
> follow-up pinning document.
Well, MTA-STS is not getting objections for having just "max-age" and
"testing", with a separate specification for an optional reporting
address (that also retroactively supports DANE). The address is not
part of the STS policy to be delivered in-band with each policy lookup.
It is a obtained separately from a TXT record in DNS.
It is easy to observe that:
1. If TLS is to support some sort of contact address for
resolving operational issues that affect TLS interoperability,
then it *should not* be restricted to just a particular
extension. Such address would be accessed independently of
the DNSSEC chain extension. Perhaps in DNS, or perhaps
solicited via a separate suitable client extension.
2. The idea of "testing" makes little sense for negotiating
a support lifetime for the DNSSEC chain extension that is
not itself subject to any sort of "testing". The complex
new behaviour here that one might have wanted to test, is
introduction of DANE-based authentication.
Expecting (client side) the extension to be supported on
an ongoing basis for a time no longer than *advertised
by the server* involves nothing one would want to "test".
If not sure about ongoing support, the server operator
should leave the field at zero, or set it to just an hour
or two.
There's no need here for anything beyond the time field. And if
we turn out to be wrong about that, then the follow-on document
can still specify a new extension with any additional fields
there, with the lifetime in this extension and the other data
in the new extension. Surely the new extension will have at
least at least a time field which can still be included in
this one, with additional fields in the new extension.
A second extension to protect a first against downgrades looks
add to me in this day and age. Integrated downgrade protection
makes more sense. Let's take a chance on getting it right from
the start.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
