From nobody Mon Aug 30 11:41:21 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9059D3A1D6B for ; Mon, 30 Aug 2021 11:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIiS73z-juI6 for ; Mon, 30 Aug 2021 11:41:13 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDF33A1D68 for ; Mon, 30 Aug 2021 11:41:13 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id i28so27547639ljm.7 for ; Mon, 30 Aug 2021 11:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hzdiC+t8B77miTypC5kgfkhGZdhMawq9zq6p3jAzSPY=; b=Z4sosfu7WVv291F9RTYEfsGC3gNdPGoRlJq+/9hLyCN8uPeV0u5vank0hZt+473Vzo UA7QBbmqRpnmY/AI5o7MAr47mXNZIV+o67Rbq6GfEJ/4tl/Kwg76IURDqNrbX4Mh0Do5 K1VuCoYAXXbAK+x7+1URnDT2yX+5nffeRk787LEvTOqzOgTa61toJ+4gq4D6Dd4HimEY kIcfXaomfObty2WRo7U3046dyXFl8iBbvVUYWLgIdbN315oy4umrhFLA+t7cShB1mwCd ErKmQ0jRzSLhWxkc+cH81FFpPQX1r29SlgFPKEbA6rNES0hJ1dd0ToMrcMRxO9UfAuu5 YMCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hzdiC+t8B77miTypC5kgfkhGZdhMawq9zq6p3jAzSPY=; b=MJr7xYZTyDkI9Raq2vR3VrzCbu5NcO84P0OYiSgQyQI1x+ypMXY557ckNs0NINHLXr 1MS5x74JKm7uMkuNDvzRBy/44FByMQR+rdF13z/zejaHXF0z/fc4TBP75l5mc3JDSk3Z 1cQW7T2X9hXDTEyqmWOurNdHtJTB8ruIEA2LrXqdQGXVCWct4y7Ohrqak7G0ed25Mo7q nJpEEh7lxsNiY6AsBhaUV5NA05PSA0gJV44qa6SgofsATquOE90ohRQj5BQdQNaxmoxP VCH0CarbK1/ROLFlSzBRiVUCMK65I/pLRJIkiI/A9T9Ho726yCT7MWzP64a56Il6O/91 baQA== X-Gm-Message-State: AOAM533VK9Qk9gqcviiKGDCWbAsuyJlUshcdpg3UBBEVzbafCaTMMNaU cfJbU4BM3eSTnveaRxYOpjTg3vzj+bvJ1gnBuqcu+8ruWXh5AQ== X-Google-Smtp-Source: ABdhPJylrTQ8Hr+VkpKROewZId7ooYoZoRID2bML7HrOleH1WxpSQ4o9O1Qt1n18jfW9kPN5SFPpb+x9exNikHChA1o= X-Received: by 2002:a2e:90d6:: with SMTP id o22mr21816611ljg.366.1630348869298; Mon, 30 Aug 2021 11:41:09 -0700 (PDT) MIME-Version: 1.0 References: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> In-Reply-To: From: Joseph Salowey Date: Mon, 30 Aug 2021 11:40:58 -0700 Message-ID: To: TLS List Content-Type: multipart/alternative; boundary="0000000000003740e105cacb2da8" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 18:41:20 -0000 --0000000000003740e105cacb2da8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This message is trimmed significantly to focus on the changes made as well as the remaining issue. The plan is to merge these PRs, spin a new version, and pass it to the AD by 6 Sept. Please send in your comments on these PRs by 3 Sept. The following PRs have been submitted to address - For s1 refactoring: https://github.com/tlswg/tls-subcerts/pull/85 - For downgrade: https://github.com/tlswg/tls-subcerts/pull/87 - For =E2=80=9Cdouble use=E2=80=9D typo and text about serve cert and DC si= gs being different: https://github.com/tlswg/tls-subcerts/pull/88 - For reference: https://github.com/tlswg/tls-subcerts/pull/90 - For TLS 1.2 intro in s7.6: https://github.com/tlswg/tls-subcerts/pull/92 On the remaining issue (below), whether to refer to the LURK I-Ds, I think that we are discussing informative references that have no impact on the I-D and stalemate on support (i.e., one person asking for them and the authors not agreeing). The issue really shouldn=E2=80=99t hold the I-D up f= rom progressing; therefore, I am going to propose that the references not be included. I will update the Shepherd write-up to note that this issue remained unresolved. Joe > On May 11, 2021, at 16:13, Daniel Migault wrote: > > > 3.2. Related Work > > > > Many of the use cases for delegated credentials can also be addresse= d > > using purely server-side mechanisms that do not require changes to > > client behavior (e.g., a PKCS#11 interface or a remote signing > > mechanism [KEYLESS]). These mechanisms, however, incur per- > > transaction latency, since the front-end server has to interact with > > a back-end server that holds a private key. The mechanism proposed > > in this document allows the delegation to be done off-line, with no > > per-transaction latency. The figure below compares the message flow= s > > for these two mechanisms with TLS 1...3 [RFC8446]. > > > > Remote key signing: > > > > Client Front-End Back-End > > |----ClientHello--->| | > > |<---ServerHello----| | > > |<---Certificate----| | > > | |<---remote sign---->| > > |<---CertVerify-----| | > > | .... | | > > > > > > Delegated credentials: > > > > Client Front-End Back-End > > | |<--DC distribution->| > > |----ClientHello--->| | > > |<---ServerHello----| | > > |<---Certificate----| | > > |<---CertVerify-----| | > > | .... | | > > > > These two mechanisms can be complementary. A server could use > > credentials for clients that support them, while using [KEYLESS] to > > support legacy clients. > > > > > > I believe that this sentence does not > > show any complementary as subcert and > > KEYLESS are targeting different version > > of TLS, so they can hardly be > > complementary. However (and luckily) > > LURK provides an extension for TLS 1.3 > > [draft-mglt-lurk-tls13] which enable a > > complementary use of these mechanisms > > these mechanisms. I believe that would > > be good to indicate the reason they > > complement each other which is that LURK > > protects the credentials for its > > operations. These operations could be > > performed in the scope of subcert or TLS > > 1.3. > > > > Note also that in a related section it > > also worth mentioning that credentials > > may be managed in different ways and > > KEYLESS represents an valuable way to > > protect and manage these credentials in > > TLS 1.2. However, KEYLESS is known to > > presents some vulnerabilities (PFS, > > signing oracle) so the protection > > remains limited while the LURK extension > > for TLS 1.2 [draft-mglt-lurk-tls12] > > addressed these issues and as a result > > should provide a better protection. > > > > > > Joe had some comments on this as well. > > This sentence is cryptic. > > I think - but I might be wrongly interpreting it - your intention is to vaguely insinuate that Joe, as co-chair already responded to that comment and somehow agree that the use of KEYLESS was justified and sufficient. I think the email you are referring to is [1] in which Joe questioned the status of draft-mglt-lurk-tls13 and Keylessl. This was followed by a response from me and Joe's response in [2] follows indicating that mentioning a technology that only works for TLS 1.2 is misleading. > > > > [1] https://mailarchive.ietf.org/arch/msg/tls/c6wYAInaB-fXsMWZMW25ass5oVI/ > > [2] https://mailarchive.ietf.org/arch/msg/tls/5RADtQkaNS2H9DDF2ILt23Jkhjg/ > > > > > > > > This section is meant to illustrate that it is possible to create a fallback with a remote oracle > > > > I am not contesting the intention, but the proposed solution does not seem work and there is little we can do about it. The current text seems technically inaccurate and seems to carry the message fallback solution can only be provided by a proprietary commercial product. This could give the impression of the IETF being instrumented for some sort of marketing campaign. > > > > Again I am not asking to remove Keyless, I am asking to list other efforts draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 as well. > > > > """ > > so a reference to a paper seemed more apt than an active draft (which would be challenging to reference in an RFC). > > """ > > It is unclear to me how the "illustrating a possible solution that is not applicable here" becomes the clauses of "paper is more apt than a draft". I might be missing something, so maybe you could clarify. > > I am reading this as having an informational reference for individual drafts draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 would be challenging. That is unclear to me what is the ground of this statement but maybe you can clarify this. At least, I cannot find any evidence of it in [1], I have not seen this raised on the mailing list. In addition, RFC8446 typically mentions RFCs, drafts, academic papers, slide presentations, emails,... draft-ietf-tls-esni also provides draft as an informational reference as well. > > > > [1] https://ietf.org/about/groups/iesg/statements/normative-informative-referen= ces/ > > > > > > Implementations can differ here, this section is not meant to be instructive. > > Maybe this is an unfortunate name for the reference. The =E2=80=9CKEYLESS= =E2=80=9D reference is generically about TLS Handshake Proxying not about Cloudflare=E2=80=99s KEYLESS SSL. The LURK paper ( https://eprint.iacr.org/2020/1366.pdf) did address some additional security considerations, and its important to highlight those. Let=E2=80=99s make tw= o changes in this section: > > OLD: > > (e.g., a PKCS#11 interface or a remote signing mechanism [KEYLESS]) > > NEW: > > (e.g., a PKCS#11 interface or a remote signing mechanism such as [REF1] or [REF2]) > > > [REF1] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. > > [REF2] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation=E2=80=9D,= IEEE TrustCom 2020, https://eprint.iacr.org/2020/1366.pdf, 2020. > > and > > > The text does not address my concern and will recap my perspective of the discussion. > > My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. > > If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. > > The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. > > I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? > > My suggestion for the text > > OLD: > > (e.g., a PKCS#11 interface or a remote signing mechanism [KEYLESS]) > > NEW: > > (e.g., a PKCS#11 interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) > > with > > [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. > [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation=E2=80=9D, IEEE TrustCom 2020, https://eprint.iacr.org/2020/1366.= pdf, 2020. > [draft-mglt-lurk-tls12] IETF draft > [draft-mglt-lurk-tls13] IETF draft > > It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, > * Cloudflare co-authors the paper appears 12 times in the 8 page paper. > * The contribution section mentions: > """ > Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] > """ > * The methodology mentions says: > > """ > We tested TLS key proxying using CloudFlare=E2=80=99s implementation, whi= ch was implemented with the following three parts: > """ > > """ > The different scenarios were set up through CloudFlare=E2=80=99s control = panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. > """ > > * Cloudflare appears in at least references > * https://github.com/cloudflare/cfssl/blob/jacob/scan-pki/scan/tls_handshake.= go#L154 > * CloudFlare Inc., =E2=80=9CCloudFlare Keyless SSL,=E2=80=9D Sep. 2014, https://www.cloudflare.com/keyless-ssl. > * N. Sullivan, =E2=80=9CKeyless SSL: The nitty gritty technical details= ,=E2=80=9D Sep. 2014, https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/= . > OLD: > > A server could use delegated credentials for clients that support them, while using [KEYLESS] to support legacy clients. > > NEW: > > A server could use delegated credentials for clients that support them, while using a remote signing mechanism to support legacy clients. > > > works for me. > --0000000000003740e105cacb2da8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This message is trimmed significantly to focus on the chan= ges made as well as the remaining issue. The plan is to merge these PRs, sp= in a new version, and pass it to the AD by 6 Sept. Please send in your comm= ents on these PRs by 3 Sept.

The following PRs have been submitted t= o address

- For s1 refactoring:=C2=A0https://git= hub.com/tlswg/tls-subcerts/pull/85
- For downgrade:=C2=A0https://github.com/tlswg/tls-subcerts/pull/87
- For =E2=80= =9Cdouble use=E2=80=9D typo and text about serve cert and DC sigs being dif= ferent:
=C2=A0 =C2=A0https://github.com/tlswg/tls-su= bcerts/pull/88
- For reference:=C2=A0https://git= hub.com/tlswg/tls-subcerts/pull/90
- For TLS 1.2 intro in s7.6:=C2= =A0https://github.com/tlswg/tls-subcerts/pull/92
On the remaining issue (below), whether to refer to the LURK I-Ds, I t= hink that we are discussing informative references that have no impact on t= he I-D and stalemate on support (i.e., one person asking for them and the a= uthors not agreeing). The issue really shouldn=E2=80=99t hold the I-D up fr= om progressing; therefore, I am going to propose that the references not be= included. I will update the Shepherd write-up to note that this issue rema= ined unresolved.

Joe

> On May 11, 2021, at 16:13, Daniel M= igault <mglt.ie= tf@gmail.com> wrote:
>
> > 3.2.=C2=A0 Related Work> >
> >=C2=A0 =C2=A0 Many of the use cases for delegated cr= edentials can also be addressed
> >=C2=A0 =C2=A0 using purely serv= er-side mechanisms that do not require changes to
> >=C2=A0 =C2=A0= client behavior (e.g., a PKCS#11 interface or a remote signing
> >= ;=C2=A0 =C2=A0 mechanism [KEYLESS]).=C2=A0 These mechanisms, however, incur= per-
> >=C2=A0 =C2=A0 transaction latency, since the front-end se= rver has to interact with
> >=C2=A0 =C2=A0 a back-end server that = holds a private key.=C2=A0 The mechanism proposed
> >=C2=A0 =C2=A0= in this document allows the delegation to be done off-line, with no
>= ; >=C2=A0 =C2=A0 per-transaction latency.=C2=A0 The figure below compare= s the message flows
> >=C2=A0 =C2=A0 for these two mechanisms with= TLS 1...3 [RFC8446].
> >
> >=C2=A0 =C2=A0 Remote key sig= ning:
> >
> >=C2=A0 =C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Front-End=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Back-E= nd
> >=C2=A0 =C2=A0 =C2=A0 |----ClientHello--->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2= =A0 =C2=A0 =C2=A0 |<---ServerHello----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 =C2=A0 |= <---Certificate----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---remote sign---->= |
> >=C2=A0 =C2=A0 =C2=A0 |<---CertVerify-----|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 ....=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
> >
> >
> >=C2=A0 =C2=A0 Delegated credentials= :
> >
> >=C2=A0 =C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Front-End=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Back-End> >=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--DC distribution->|
> >=C2=A0 = =C2=A0 =C2=A0 |----ClientHello--->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 =C2=A0 |<= ---ServerHello----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 =C2=A0 |<---Certificate----|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= > >=C2=A0 =C2=A0 =C2=A0 |<---CertVerify-----|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 ....=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= > >
> >=C2=A0 =C2=A0 These two mechanisms can be complementa= ry.=C2=A0 A server could use
> >=C2=A0 =C2=A0 credentials for clie= nts that support them, while using [KEYLESS] to
> >=C2=A0 =C2=A0 s= upport legacy clients.
> >
> > <mglt>
> > = I believe that this sentence does not
> > show any complementary a= s subcert and
> > KEYLESS are targeting different version
> = > of TLS, so they can hardly be
> > complementary.=C2=A0 Howeve= r (and luckily)
> > LURK provides an extension for TLS 1.3
>= > [draft-mglt-lurk-tls13] which enable a
> > complementary use= of these mechanisms
> > these mechanisms. I believe that would> > be good to indicate the reason they
> > complement each= other which is that LURK
> > protects the credentials for its
= > > operations. These operations could be
> > performed in t= he scope of subcert or TLS
> > 1.3.
> >
> > Note= also that in a related section it
> > also worth mentioning that = credentials
> > may be managed in different ways and
> > = KEYLESS represents an valuable way to
> > protect and manage these= credentials in
> > TLS 1.2. However, KEYLESS is known to
> = > presents some vulnerabilities (PFS,
> > signing oracle) so th= e protection
> > remains limited while the LURK extension
> = > for TLS 1.2 [draft-mglt-lurk-tls12]
> > addressed these issue= s and as a result
> > should provide a better protection.
> = > </mglt>
> >
> > Joe had some comments on this = as well.
> > <mglt> This sentence is cryptic.
> > I= think - but I might be wrongly interpreting it - your intention is to vagu= ely insinuate that Joe, as co-chair already responded to that comment and s= omehow agree that the use of KEYLESS was justified and sufficient. I think = the email you are referring to is [1] in which Joe questioned the status of= =C2=A0 draft-mglt-lurk-tls13 and Keylessl. This was followed by a response = from me and Joe's response in [2] follows indicating that mentioning a = technology that only works for TLS 1.2 is misleading.=C2=A0 =C2=A0 =C2=A0> >
> > [1]=C2=A0https://mailarchive.ietf.org/arch/msg/tls/c6wYAInaB-fXsMWZMW25ass5oVI/<= /a>
> > [2]=C2=A0http= s://mailarchive.ietf.org/arch/msg/tls/5RADtQkaNS2H9DDF2ILt23Jkhjg/
&= gt; >=C2=A0
> > </mglt>
> >
> > This se= ction is meant to illustrate that it is possible to create a fallback with = a remote oracle
> > <mglt>
> > I am not contesting = the intention, but the proposed solution does not seem work and there is li= ttle we can do about it. The current text seems technically inaccurate and = seems to carry the message fallback solution can only be provided by a prop= rietary commercial product. This could give the impression of the IETF bein= g instrumented for some sort of marketing campaign.
> >
> &g= t; Again I am not asking to remove Keyless, I am asking to list other effor= ts draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 as well.
> >> > """
> > so a reference to a paper seemed= more apt than an active draft (which would be challenging to reference in = an RFC).
> > """
> > It is unclear to me h= ow the "illustrating a possible solution that is not applicable here&q= uot; becomes the clauses of=C2=A0 "paper is more apt than a draft"= ;. I might be missing something, so maybe you could clarify.
> > I= am reading this as having an informational reference for individual drafts= draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 would be challenging. That= is unclear to me what is the ground of this statement but maybe you can cl= arify this. At least, I cannot find any evidence of it in [1], I have not s= een this raised on the mailing list.=C2=A0 In addition, RFC8446 typically m= entions RFCs, drafts, academic papers, slide presentations, emails,...=C2= =A0 =C2=A0draft-ietf-tls-esni also provides draft as an informational refer= ence as well.
> >
> > [1]=C2=A0https://ietf.org/about/groups/iesg/statements/n= ormative-informative-references/
> > </mglt>
> >= ;=C2=A0
> > Implementations can differ here, this section is not m= eant to be instructive.
>
> Maybe this is an unfortunate name f= or the reference. The =E2=80=9CKEYLESS=E2=80=9D reference is generically ab= out TLS Handshake Proxying not about Cloudflare=E2=80=99s KEYLESS SSL. The = LURK paper (https://eprint.iacr.org/2020/1366.pdf) did addr= ess some additional security considerations, and its important to highlight= those. Let=E2=80=99s make two changes in this section:
>
> OLD= :
>
> (e.g., a PKCS#11 interface or a remote signing mechanism = [KEYLESS])
>
> NEW:
>
> (e.g., a PKCS#11 interface = or a remote signing mechanism such as [REF1] or [REF2])
>
>
= > [REF1] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake= Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015.
>
> [= REF2] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fie= au, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation=E2=80= =9D, IEEE TrustCom 2020,=C2=A0https://eprint.iacr.org/2020/1366= .pdf, 2020.
>
> and
>
> <mglt>
> Th= e text does not address my concern and will recap my perspective of the dis= cussion.
>
> My initial comment was that the reference [KEYLESS= ] points to a solution that does not work with TLS 1.3 and currently the on= ly effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this r= eference to be mentioned and I do not see it in the text proposed text.
= >
> If the intention with [KEYLESS] is to mention TLS Handshake Pr= oxying techniques, then I argued that other mechanisms be mentioned and amo= ng others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address diff= erent versions of TLS. This was my second concern and I do not see any of t= hese references being mentioned.
>
> The way I understand your = response is that the paper pointed out by [KEYLESS] is not Cloudflare's= commercial product but instead a generic TLS Handshake proxying and that y= ou propose to add a reference to an academic paper that discusses the LURK = extension for TLS 1.2.
>
> I appreciate that other solutions - = and in this case LURK, are being considered. I am wondering however why dra= ft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and wh= y draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to av= oid any reference of the work that is happening at the IETF. Is there anyth= ing I am missing ?
>
> My suggestion for the text
>
&g= t; OLD:
>
> (e.g., a PKCS#11 interface or a remote signing mech= anism [KEYLESS])
>
> NEW:
>
> (e.g., a PKCS#11 inte= rface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [dra= ft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS])
>
> with
&g= t;
> [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS = Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015.
> = [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra,= S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation= =E2=80=9D, IEEE TrustCom 2020,=C2=A0https://eprint.iacr.org/202= 0/1366.pdf, 2020.
> [draft-mglt-lurk-tls12] IETF draft
> [d= raft-mglt-lurk-tls13] IETF draft
>
> It is unclear to me what i= s generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for = clarification, the paper clearly refers to Cloudflare commercial products a= s opposed to a generic mechanism, and this will remain whatever label will = be used as a reference. Typically,
> * Cloudflare co-authors the pape= r appears 12 times in the 8 page paper.
> * The contribution section = mentions:
> """
> Our work focuses specifically = on the TLS handshake proxying system implemented by CloudFlare in their Key= less SSL product [6], [7]
> """
> * The methodol= ogy mentions says:
>
> """
> We tested TLS= key proxying using CloudFlare=E2=80=99s implementation, which was implemen= ted with the following three parts:
> """
>
&= gt; """
> The different scenarios were set up through = CloudFlare=E2=80=99s control panel. In the direct handshake handshake scena= rio, the site is set up with no reverse proxy. In the scenario where the ke= y is held by the edge server, the same certificate that was used on the ori= gin is uploaded to CloudFlare and the reverse proxy is enabled for the site= .
> """
>
> * Cloudflare appears in at lea= st references
>=C2=A0 =C2=A0*=C2=A0https://github.com/cloudflare/cfssl/blob/jacob/scan-= pki/scan/tls_handshake.go#L154
>=C2=A0 =C2=A0* CloudFlare Inc., = =E2=80=9CCloudFlare Keyless SSL,=E2=80=9D Sep. 2014,=C2=A0http= s://www.cloudflare.com/keyless-ssl.
>=C2=A0 =C2=A0* N. Sullivan, = =E2=80=9CKeyless SSL: The nitty gritty technical details,=E2=80=9D Sep. 201= 4,=C2=A0https://blog.clou= dflare.com/keyless-ssl-the-nitty-gritty-technical-details/.
>=C2= =A0 OLD:
>
> A server could use delegated credentials for clien= ts that support them, while using [KEYLESS] to support legacy clients.
&= gt;
> NEW:
>
> A server could use delegated credentials f= or clients that support them, while using a remote signing mechanism to sup= port legacy clients.
>
> <mglt>
> works for me.
= > </mglt>

--0000000000003740e105cacb2da8--