Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Joseph Salowey <[e-mail]>]

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 <[e-mail]> 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>