Thanks Ted,
On 2024-07-26 06:40, Ted Hardie wrote:
Hi Soni,
Thanks for the time and energy put into the BoF presentation.
Thinking about the draft and presentation a bit more, I think it may
be possible to tease apart the issues a bit.
Part of the discussion was about the historical use of "userinfo" and
whether or not it was or should be deprecated. There are clearly
differences of opinion there, and it would take time and care to come
to a consensus around them. One way to do that would be to write an
applicability statement. If you haven't seen one of those in the IETF
context before, it's a particular kind of RFC which lays out when a
particular protocol element or approach is beneficial and when it is
problematic. RFC 6815 is one example; it clarifies that the methods
in RFC 2544 are intended for test environments only and not for
production environments. An applicability statement on "userinfo"
would not deprecate it completely, simply update the community's
understanding of its utility. That may well be worth doing, but it is
distinct from the question of what should be done in the cases where
the use of userinfo is problematic.
we see. we hadn't heard of these.
The second part of the discussion was around the proposed scheme,
"auth". While the draft describes this as a meta-scheme, it is
syntactically a standard URI scheme in which the elements are composed
of the scheme name, a method, and a set of query elements, at least
one of which is itself a URI. From my perspective, there are a few
issues which would need to be addressed:
(oh, maybe we should make a separate draft detailing "meta-schemes"?
("meta-URIs"? we could bikeshed that name...) probably the way to go, as
that might be an useful discussion too.)
1) The scheme name is very generic and it would likely be appropriate
to update that to something more specific.
yeah... fwiw BCP 35 only says "scheme [names] SHOULD NOT use names that
are [...] very general purpose" (i.e. it's not a MUST NOT), and we would
argue the proposed URI is scoped to deal with authentication, but
maybe. we're not sure what would be more specific... we'll leave that
as an open question for now.
2) The document is not yet clear on the set of methods, in part
because the BNF:
auth-method-nm-char = ALPHA / DIGIT / "-" / "_"
appears unbounded but the IANA considerations reference an assignment
policy of IETF review. Is that for the methods, or was that
referencing the URI scheme registry itself?
indeed that is for the methods. we feel like having to update the BNF
whenever adding a new method would be a little too heavyweight. on the
other hand we can see an argument for restricting it, to prevent every
other vendor from making up their own methods.
this proposal should've had two methods: the already-described "info"
method (for compatibility with userinfo), and a "pm" ("pass"? "manager"?
also bikesheddable, refers to password managers) method, but we're not
versed in password managers enough to come up with something on our
own. (there are also pkcs11 URIs, RFC 7512 (from which we pulled some
of the ABNF, even), so "auth by PKCS #11" could be considered as well,
but we know even less about PKCS #11...)
3) There is normative language specifying the behavior of operating
systems:
When one program attempts to open an auth URI, the operating system
MUST NOT open another program to handle the auth URI.
That's very difficult to enforce, and a different approach should
likely be discussed. There is similar language throughout the draft
discussing the syntax as a way to avoid link recognition systems. As
part of a security considerations section, it would be good to work
through what happens when those are updated with an understanding of
this new scheme; there appears to be a strong risk that they would be
updated to parse the embedded URI.
oh, alright. hmm... we wouldn't generally consider "the embedded URI
gets turned into a clickable link" in our threat model... except... oh,
we suppose these same link recognition libraries get used by e.g. email
filtering software, it could definitely cause problems if the email
filter ignores the embedded URI while the email client turns it into a link.
we believe there are competing factors at play here:
- for the "leaking credentials (or credential-related metadata) to a
different app" issue, it doesn't really matter, because the embedded URI
doesn't include the metadata. (it's fine if it gets clicked and passed
around.)
- for the "embedded URI may be malicious" issue however, well... there's
filtering links, and then there's making them clickable. it seems to us
you'd want different kinds of link recognition systems targeted at these
two different needs. (also, this may well be an issue today... guess
we'll find out soon enough.)
we feel like we could go either way, so long as we either make it
consistent or recognize the different needs. oh and take into account
existing software.
Addressing these and requesting provisional registration would be
fairly lightweight, but seeking a permanent registration would likely
need some additional work and a demonstration that there are likely to
be implementations of the scheme. In the web context, browser
interest in particular would be a useful sign of future adoption.
I look forward to additional discussion on the list,
best regards,
Ted Hardie
On Tue, Jul 23, 2024 at 11:59 PM Soni "It/Its" L.
<[email protected] <mailto:fakedme%[email protected]>> wrote:
hello,
draft link: https://datatracker.ietf.org/doc/draft-soni-auth-uri/
we discussed this in the DISPATCH session, and the outcome was
that we
should discuss it here.
so, to re-state our goal, we want to get rid of userinfo
altogether, not
just in http but in... just about everything really. but we know we
can't "just" do that, we have to acknowledge where it's still used,
provide alternatives, and all that stuff... (particularly
databases and
ORMs, whose connect method often just takes a single string where
you're
supposed to just embed authentication details...)
and there were comments saying we can't get rid of it. we like to
think
that's not entirely true, but it would take a lot of work, and some
churn, to get there. importantly, the inconsistencies we brought up
(or... we'd rather call them footguns especially for those working on
new URI schemes) don't just apply to individual apps but also to
interactions between apps (granted, our proposal is also pretty
explicit
about getting in the way of interactions between apps, but at
least you
can't attempt to repurpose our proposal because - unlike userinfo
- one
of the things it does is decouple the concepts of authentication from
the target URI scheme).
we do see that our proposal can't actually restrict userinfo in the
embedded URI, at least as per RFC 8820, section 2.2
https://www.rfc-editor.org/rfc/rfc8820#name-uri-authorities (not
to be
confused with section 2.1 (we feel sorry for the correspondent on the
ART list who kept telling us to look at section 2.1 in increasing
frustration...)), and... well, browsers are certainly not
complying with
that because they absolutely do strip userinfo from arbitrary
(non-http(s)) URIs. but aside from that it just means we might
have to
change either our proposal, BCP 190, or maybe RFC 3986? not entirely
sure about that last one.
(also, we just realized, looking over RFC3986 again... it only
deprecates "user:password", despite the clear acknowledgement of
semantic attacks involving just the username portion (the provided
example doesn't use the "user:password" format). why is that?)
thanks! (and apologies for the delay, anxiety is hard)
(p.s.: so if we're understanding correctly WIT is for URIs as in the
generic syntax, and ART is for URI schemes? we would appreciate
clarification on this.)
--
plural system (tend to say 'we'), it/she/they, it instead of you
--
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
plural system (tend to say 'we'), it/she/they, it instead of you
--
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]
