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 “double use” typo and text about serve cert and DC sigs 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’t hold the I-D up from 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 <mglt.i...@gmail.com> wrote: > > > 3.2. Related Work > > > > Many of the use cases for delegated credentials can also be addressed > > 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 flows > > 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. > > > > <mglt> > > 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. > > </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 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/ > > > > </mglt> > > > > This section 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 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-references/ > > </mglt> > > > > Implementations can differ here, this section is not meant to be instructive. > > Maybe this is an unfortunate name for the reference. The “KEYLESS” reference is generically about TLS Handshake Proxying not about Cloudflare’s 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’s 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. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, https://eprint.iacr.org/2020/1366.pdf, 2020. > > and > > <mglt> > 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”, 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’s implementation, which was implemented with the following three parts: > """ > > """ > The different scenarios were set up through CloudFlare’s 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., “CloudFlare Keyless SSL,” Sep. 2014, https://www.cloudflare.com/keyless-ssl. > * N. Sullivan, “Keyless SSL: The nitty gritty technical details,” 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. > > <mglt> > works for me. > </mglt>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls