LGTM3

Comment about double checking the security review stands.

(We decided this was fine two weeks ago but not all the necessary mails ended up on the list - our fault, good that you pinged us!)

/Daniel

On 2022-02-16 13:39, 'Victor Vasiliev' via blink-dev wrote:
Friendly ping.

On Wed, Feb 2, 2022 at 11:53 AM Chris Harrelson <chris...@chromium.org> wrote:

    LGTM2

    My understanding is that there is a security/privacy review
    ongoing to double-check this feature, so if there is an LGTM3
    please make sure that review has concluded as well.

    On Wed, Feb 2, 2022 at 3:28 AM Yoav Weiss <yoavwe...@chromium.org>
    wrote:

        LGTM1

        On Thursday, January 20, 2022 at 7:08:59 AM UTC+1 Victor
        Vasiliev wrote:

            Contact emails

            yhir...@chromium.org <mailto:yhir...@chromium.org>,
            vasi...@chromium.org <mailto:vasi...@chromium.org>


            Explainer

            https://github.com/w3c/webtransport/blob/main/explainer.md
            <https://github.com/w3c/webtransport/blob/main/explainer.md>


            Spec

            
https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes
            
<https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes>


            WebTransport has been already covered by a series of TAG
            reviews (389
            <https://github.com/w3ctag/design-reviews/issues/389>, 669
            <https://github.com/w3ctag/design-reviews/issues/669>).


            Summary

            In WebTransport, the serverCertificateHashes option allows
            the website to connect to a WebTransport server by
            authenticating the certificate against the expected
            certificate hash instead of using the Web PKI.  This
            feature allows Web developers to connect to WebTransport
            servers that would normally find obtaining a publicly
            trusted certificate challenging, such as hosts that are
            not publically routable, or virtual machines that are
            ephemeral in nature.


            During the WebTransport Intent to Ship email thread
            
<https://groups.google.com/a/chromium.org/g/blink-dev/c/kwC5wES3I4c>,
            concerns were raised regarding the security considerations
            of this portion of the spec being incomplete.  We believe
            that we have addressed those concerns (notably, in this PR
            <https://github.com/w3c/webtransport/pull/375>).


        Please followup on the PR to ensure it lands. Thanks! :)

              In terms of the actual code behavior, the only major
            difference since the previous thread is that we no longer
            allow RSA keys for the certificates.


            Link to “Intent to Prototype” blink-dev discussion

            
https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ
            
<https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ>


            Is this feature supported on all six Blink platforms
            (Windows, Mac, Linux, Chrome OS, Android, and Android
            WebView)?

            Yes.


            Debuggability

            The certificate-related errors for WebTransport sessions
            are logged into the developer console.


            Measurement

            The use of this feature is tracked by the
            WebTransportServerCertificateHashes use counter.


            Risks

            Interoperability and Compatibility

            There is some discussion about adding a mechanism to
            prevent websites from using this feature via an HTTP
            header (either CSP or a new header).  Some of the
            proposals could potentially break existing usage under
            certain conditions (e.g. if a webpage both uses
            serverCertificateHashes and has a connect-src directive,
            and we decide to extend connect-src); I expect for those
            cases to be sufficiently niche to ultimately not be a
            problem, and the question itself is of fairly low priority
            as there does not seem to be a strong security reason for
            a website to restrict serverCertificateHashes.


        Are you planning to file a separate intent once those plans
        materialize?


            Gecko: worth prototyping
            
<https://github.com/mozilla/standards-positions/issues/167#issuecomment-1015951396>

            WebKit: no signal
            
<https://lists.webkit.org/pipermail/webkit-dev/2021-September/031980.html>

            Web / Framework developers: positive (we have received
            indication in the past that serverCertificateHashes is a
            blocker for migrating from WebRTC at least one of them)


            Ergonomics

            The API is roughly modeled after a similar WebRTC API
            (RtcDtlsFingerprint), with a noted improvement that the
            certificate hash no longer requires to be serialized into
            a specific format.


            Activation

            Using this feature would require web developers to design
            their application in a way that supports generating and
            distributing ephemeral certificates on demand.


            Security

            Security considerations for this feature are discussed at
            length in PR #375
            
<https://pr-preview.s3.amazonaws.com/vasilvv/web-transport/pull/375.html#certificate-hashes>.


            Is this feature fully tested by web-platform-tests
            
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
            Link to test suite results from wpt.fyi <https://wpt.fyi>.

            WebTransport itself is tested by web-platform-tests; this
            specific feature requires infra support that is currently
            not available (issue
            <https://github.com/web-platform-tests/wpt/issues/32463>).


            Entry on the feature dashboard <http://www.chromestatus.com/>

            https://chromestatus.com/feature/5690646332440576
            <https://chromestatus.com/feature/5690646332440576>

-- 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/2a591c7e-ef31-4015-8b34-256e12bcfce3n%40chromium.org
        
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a591c7e-ef31-4015-8b34-256e12bcfce3n%40chromium.org?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/CAAZdMaetk7JoQ-gOmhcPKgRh2uo%2BnKNeG%3DYOF%3Dnrat0YVPUgBQ%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaetk7JoQ-gOmhcPKgRh2uo%2BnKNeG%3DYOF%3Dnrat0YVPUgBQ%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/546df1df-f975-85d1-ff9b-b59eadeab4a8%40gmail.com.

Reply via email to