+ericlaw@microsoft Eric, could you perhaps provide updated numbers of digest auth usage? (i'm referring to your previous comment here: https://bugs.chromium.org/p/chromium/issues/detail?id=1160478#c6)
On Mon, Jun 26, 2023, 18:09 David Benjamin <david...@chromium.org> wrote: > Not an expert in our HTTP auth code overall, but I don't see any metrics > for specifically digest auth vs. other HTTP auth types either. > > As an upper bound, I wouldn't expect HTTP auth of any form to be common. > This whole space is mostly a legacy feature as far as the web is concerned. > I doubt usage would ever completely fall off, but it's not exactly a > preferred path, or a space that sees much active work. Making modern hashes > available for Digest seems reasonable enough, I suppose, but I wouldn't > want to spend more time on it than that. :-) > > But I couldn't find good metrics for the upper bound either. > Net.HttpResponseCode says how often we see 401 and 407 response codes (very > rarely), but that's a little misleading. If I recall (not an HTTP auth > expert), for the simpler auth types (Basic and Digest), cached credentials > are sufficient to preemptively send a (Proxy-)Authorization header. That > means we'll only see a 401 or 407 on the first go around, up to some > interesting rules around which paths an auth entry is scoped to. > > In terms of breakage risk, since this protocol is server-offer > / client-select, the client never sends the list of values it supports. > That means only servers that actually claim to support the new hashes will > see any change at all. So the risk is limited to early-adopting servers > that have adopted the new thing but gotten it wrong. Or if we got it wrong. > :-) (No particular opinions on my end as to whether that makes it worth > flag-protecting.) > > On Mon, Jun 26, 2023 at 10:46 AM Rick Byers <rby...@chromium.org> wrote: > >> Hi Deomid, >> Thanks for the contribution! Do you know if chromium has any metrics on >> how common digest auth is? I took a quick look and didn't find one myself. >> +David >> Benjamin <david...@chromium.org> also. Technically all new APIs (which >> includes protocols) require a killswitch flag >> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >> since >> we've seen even new APIs break websites sometimes (eg. in this case >> presumably it would be from a misconfigured server). But if we have data >> showing the usage of digest auth is small / insignificant enough, I'd >> personally be receptive to an argument that that is unnecessary extra >> bureaucracy. >> >> Also it would be nice to know if WebKit has an opinion on this, could you >> file >> a position request >> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u> >> please? >> >> Thanks, >> Rick >> >> On Wed, Jun 21, 2023 at 3:31 PM Deomid "rojer" Ryabkov <ro...@rojer.me> >> wrote: >> >>> Hi Daniel, >>> >>> I do not anticipate immediate impact. By and large, this is not >>> currently used because the most popular browser engine doesn't support it. >>> So people just use MD5, as in the bad old days. >>> If we ship this tomorrow, nothing changes: servers still send legacy MD5 >>> challenges, which we continue to support. >>> As awareness of SHA-256 support by Chrome/Blink-based browser spreads, I >>> expect service administrators to gradually start transitioning away from >>> MD5. >>> The RFC specifies use of multiple algorithm challenges by sending >>> multiple WWW-Authenticate headers, so there's a good transition path there >>> for service admins (send both SHA-256 and MD5 challenges, phase out MD5 >>> eventually). >>> I verified that with my current code this works as specified (order of >>> headers specifies server's preference). >>> Firefox already supports SHA-256, so there's already a capable browser >>> in the wild, but since it's a minority there isn't much use yet. >>> As far as deviating from Firefox in also supporting SHA-512-256 and >>> userhashing, it's again a no-op initially: these won't be used unless >>> servers explicitly specify that they can be used (for example, for lighttpd >>> there's an explicit option to enable username hashing, off by default). >>> If Firefox catches up and also implements these, then we might start >>> seeing adoption. >>> >>> >>> On Wed, 21 Jun 2023 at 11:18, Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> I am missing the compatibility picture here. How will this affect >>>> existing web pages, and what happens to browsers that do not support this >>>> is we add support? >>>> >>>> /Daniel >>>> On 2023-06-20 18:13, Deomid "rojer" Ryabkov wrote: >>>> >>>> Contact emails roj...@gmail.com >>>> >>>> Explainer None >>>> >>>> Specification https://datatracker.ietf.org/doc/html/rfc7616 >>>> >>>> Summary >>>> >>>> https://datatracker.ietf.org/doc/html/rfc7616 specifies SHA-256 and >>>> SHA-512-256 algorithms for the HTTP digest authentication scheme, in >>>> addition to the obsolete and insecure MD5. It also specifies way of >>>> concealing the username, provided that server supports it. Firefox supports >>>> algorithm=SHA-256 since 93, but not SHA-512-256 or username hashing. >>>> https://chromium-review.googlesource.com/c/chromium/src/+/4611879 is >>>> the pending CL. >>>> >>>> >>>> Blink component Blink>Network >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>> >>>> TAG review None >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> *Gecko*: Shipped/Shipping ( >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=472823) >>>> >>>> *WebKit*: No signal >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> >>>> Debuggability >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? No >>>> >>>> Flag name >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 >>>> >>>> Estimated milestones >>>> Shipping on desktop 116 >>>> Shipping on Android 116 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5139896267702272 >>>> >>>> Links to previous Intent discussions >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> Deomid "rojer" Ryabkov >>>> ro...@rojer.me >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>> >>> -- >>> Deomid "rojer" Ryabkov >>> ro...@rojer.me >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%40mail.gmail.com.
