ok, added a flag (enabled by default). On Thu, 29 Jun 2023 at 10:21, Rick Byers <rby...@chromium.org> wrote:
> Agreed that given we don't have metrics proving the usage is really rare, > we should err on the side of caution and follow the "all new APIs need a > killswitch" guideline > <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> > here. It should be straightforward to do so, but please let us know > otherwise. > > Rick > > On Thu, Jun 29, 2023 at 3:26 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> Thanks for working on this! >> >> Would you be able to put this behind a flag >> <https://chromium.googlesource.com/chromium/src/+/master/docs/how_to_add_your_feature_flag.md#step-1_adding-a-new>, >> to reduce any risk this might hit in the wild? >> >> It'd also be good to add use-counters to know how common these digests >> are, but given that the code is fully contained in net/ this might be a bit >> tricky. Maybe +Adam Rice <ri...@chromium.org> and team would be able to >> help with adding some metrics there? That's not a blocker for this intent, >> but would help shed light on overall usage of this feature. >> >> On Wed, Jun 28, 2023 at 4:15 PM Deomid "rojer" Ryabkov <ro...@rojer.me> >> wrote: >> >>> +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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%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/CABFmFwqdQE671X3WCdLO2HtYP1hypmkZTGh1p-KVwQjM1p9xYQ%40mail.gmail.com.
