On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Apr 26, 2018, at 10:50 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > >> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we > >> find: > >> > >> * a lifetime field > >> * enforce vs. test > >> * a report URI > >> > >> This specification is always "enforce" (though my pull request > >> changes a MUST use DANE to a SHOULD with some necessary added > >> conditions) and since the report URI is in good measure to > >> support non-enforce mode, we're back to just max-age. > >> > > But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments above about > why we shouldn't do this persuasive.) Standardizing this functionality > would require resolving these issues. > > We should observe that "enforce vs. test" is already moot, this document > implies enforce. If you wanted a test mode and a reporting URI, these > would have to be part of the present extension. You seem to be assuming that the only thing you might want to test is the DANE chain for this specific connection. Consider the case where you have a big server farm and you want to roll this mechanism out, but you're concerned about whether you're getting every server configured properly. You set this with pinning on and test mode + reporting URI, and then wait to see if you get reports, which would indicate that a server is misconfigured. Anyway, we're now having the discussion about exactly what would be be required to make pinning work, which, as I said, demonstrates that it's premature to just add a placeholder age field for this functionality. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
