On Tue, Nov 06, 2018 at 10:05:14AM -0600, Benjamin Kaduk wrote:
> Of course! But if we don't precisely specify those semantics, we expect
> to get DISCUSS positions at IESG evaluation (as "not interoperably
> implementable").
Yes, that's why the draft once updated will need to explain the
semantics, rationale, limitations, risks, ... of any approach it
ultimately takes.
> > why carry the bits. For example, already in -07 there is clear text
> > specifying that the transported records can be cached for their DNS TTL,
> > and that once delivered DANE records should not be ignored on failure.
> [...]
> > That rather looks like semantics to me, much more than transport some bits.
>
> Is it new semantics for this TLS extension, or just the semantics of "you
> have a DANE record; this is what you do with it"?
Well, in -07 there is also a TOFU unilateral pinning proposal, added
in a hasty (and little noticed at the end of the original process)
attempt to close the gap between promised and viable scope. Otherwise,
yes, it mostly tries to parallel what happens when TLSA records are
obtained directly from DNS.
> > I really don't think that at this juncture it is productive to wipe the
> > slate clean and consider all possible proposals, even ones that nobody
> > has put forward as yet. Why would we want to do that. There is clearly
>
> When we do work at the IETF, proposals are not presented as a "take it
> or leave it" option -- usually, they are starting points for further
> analysis and discussion: "is this optimal?", "is it better if we tweak
> it in this way?", etc. I am presenting a framework in which to try to
> answer these questions, starting from the proposal on the table.
Please pardon my frustration with the recent deadlock. If my
objection is excessive, I apologise. That said, I do hope that the
discussion will have some focus.
* We've made a substantive proposal, explaining both the need for
downgrade protection to make the extension more widely applicable,
and that risks do not entail anything like an HPKP footgun.
* The chairs have summarized the issues, and asked for any substantive
objections to the summary... none were made.
* I do think it is time to actually settle two basic questions:
* Expand the scope to cover existing applications, or
rewrite the introduction to say this is a DPRIVE-only
extension to TLS, and explain why the scope should not
be any wider.
* Get past instinctive reactions to pinning the extension
(which bears little resemblance to HPKP), and if so move on
to figuring out the design parameters. Maximum duration,
any gradual scaling to give server operators time to adopt,
or no scaling because the risk of hostile pinning is minor
and not worth the complexity, ...
Yes, of course other topics can also be discussed, but I hope not
to the exclusion of moving past the present roadblocks. This is
not the end of the process, more of a new beginning, which once
progress resumes will leave room for additional considerations.
> > And any client with a decent network environment can just query the
> > DNS directly, and never use the extension and have the record hot
> > in the local cache. So there's no need for anything too complicated
> > here. We just need to provide as much of the downgrade-resistance
> > that DNSSEC gives automatically, also to clients that for some time
>
> I think I'm confused about what you mean by "the downgrade-resistance
> that DNSSEC gives automatically".
When a client using this extension asks the server for a DNSSEC
chain, absent any prior commitment by the server, it cannot expect
the answer, and not getting one will be the default "normal", not
a failure
When a validating DNS resolver asks a DNS question it always expects
a DNS answer, failing to get an answer, or getting an invalid answer
is a failure. Sadly in some captive portals and behind some crippled
home CPE equipment, failure is more common than we'd like, but still
it is clear that getting no answer, or an invalid answer is a
failure.
> > I think at this point hypothetical semantics is not a helpful direction.
>
> I'm sorry you feel that way. We've seen a few participants raise a
> specific pinning proposal but they seem to have squelched discussion of
> any other pinning options.
There have been no substantive alternative pinning proposals. All
I've seen is suggesting for a "testing" mode, which is not viable
here, as already explained, and out-of-band reporting is also not
a good option, an in-band alert would be far simpler and better.
Once again sorry if you feel shut down, not my intention, just
trying to get some focus on specific refinements or objections, so
we can move forward (or not) and if so then entertain more suggested
refinements.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
