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

Joseph Salowey <joe@salowey.net> Wed, 01 July 2020 05:24 UTC

Return-Path: <joe@salowey.net>
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 AF4243A0D13 for <tls@ietfa.amsl.com>; Tue, 30 Jun 2020 22:24:42 -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 xI4BGs9UOwfF for <tls@ietfa.amsl.com>; Tue, 30 Jun 2020 22:24:39 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 0FBC33A0D12 for <tls@ietf.org>; Tue, 30 Jun 2020 22:24:38 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id o38so17538552qtf.6 for <tls@ietf.org>; Tue, 30 Jun 2020 22:24:38 -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=Xirfa+TJ8De0PdeKy+0iuU3QN/jqKB8IR32KlxU0oxw=; b=Lx2UqqYkWQwotBcom54Xu/tyZVl23LSpZYi3rmNgVU/Li+cJKHVSmRZDtMxd2AnmK5 2FGdOTcQ2Mbr2S+iNXdArsMHeUj0jmnrT8x8Ms6vjf/VAy4gphG+9Z6ZoE9FY4mSyiEW Rbgmw/kgDtNTTh5qIsAQqS5jmVZDZUUhW9KUm45ob+pBlm/GhR6eMXPokOSOggIBQ53L i4F5W7b3BIpp7VORBfVCr25rDGLdTaw5pzFVnLAjuiijmj7jcC6LgmzFo4KvzRE6DWgi 3IbQ/DGaUfPr7tiiomVnz0FV41DJgK9AOoqdxUlQ5rlHfBV0/tt1J8tKiHUOBT0fXVkj /GUA==
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=Xirfa+TJ8De0PdeKy+0iuU3QN/jqKB8IR32KlxU0oxw=; b=GjbgG4w0sRB/qI3lCJgj4C2OHXH3LyIoayrz27gkgKUuwA3PANJ8Je1h95YoBrOP6Y 7ePp8ggnKwNvCRj2QF6JE9WXM04s2ngqX8DN2TNBQ4CMbmWhHtlbcb9O7I68L4vV76R4 PnH1LkP3oDNGk3xc0knHHZqnpto3F2tAN3btrIEUF6BHc/bx5s25cJ7LbuexcHxTzD0u gapaYz63YkqpDrJLW6gUSmmwGGVn5o17fbD8zhttX7o+LAHcdgM+MfxUEoJzDV3hqygO fp/JedoAtYKlEVGU/4SshCFnFBKxVnodjAqzm1+J6KXOcToW73bJqUVSUtB7oCaSDZhL JsvQ==
X-Gm-Message-State: AOAM533S4MIWn2/2T3HBlky4BJzyqRVF6IGjWCEiaKE2WONVQv9r2WVn eQSgzdnb8Q5HkPZx7LT1ir3pC3CFrfFN1YKt/Mb9TA==
X-Google-Smtp-Source: ABdhPJxG0p5xT8nkE99QPloK2HR6/WCF/TOdsm0M8GHpcgiSpG5tsqSOhbVjoYjKsB+ZcFQiSIE8tc0cHIUaeU413qw=
X-Received: by 2002:ac8:22d2:: with SMTP id g18mr25140104qta.38.1593581077505; Tue, 30 Jun 2020 22:24:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoB3LDZ2uMJkMyDxMbbWy6yScYuURVB7GqTiwVS0f2UkTw@mail.gmail.com> <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> <MW3PR15MB37855738A57E0192BBE7796CE36E0@MW3PR15MB3785.namprd15.prod.outlook.com> <CAOgPGoA18+P=XTpB2cLBYTP7r2=XTyaQ8u6nVp=+UcFOhrcBoA@mail.gmail.com> <SA0PR15MB3791976C5184C780C56DEF35E36F0@SA0PR15MB3791.namprd15.prod.outlook.com>
In-Reply-To: <SA0PR15MB3791976C5184C780C56DEF35E36F0@SA0PR15MB3791.namprd15.prod.outlook.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 30 Jun 2020 22:24:26 -0700
Message-ID: <CAOgPGoB2yLGMQUNHeUP0c-6cfrC4E_=ozy-ALPf7-=rXzFX-UA@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000bbac005a95a82e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5RADtQkaNS2H9DDF2ILt23Jkhjg>
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 05:24:43 -0000

On Tue, Jun 30, 2020 at 9:10 AM Daniel Migault <daniel.migault@ericsson.com>
wrote:

> Hi Joe,
>
> Thanks for the feed back, please find my responses inline.
>
> Yours,
> Daniel
>
> ------------------------------
> *From:* Joseph Salowey <joe@salowey.net>
> *Sent:* Monday, June 29, 2020 10:01 PM
> *To:* Daniel Migault <daniel.migault@ericsson.com>
> *Cc:* Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>rg>; <tls@ietf.org> <
> tls@ietf.org>
> *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
>
> HI Daniel
>
> Some comments inline below:
>
> On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
> Hi,
>
> The draft has a number of nits and errors. Among others:
>
> The related work section mentions KEYLESS and subcert being complementary
> that is KEYLESS can perform the operations associated to the DC and/or
> those associated to the cert key. I do not think that is correct. KEYLESS
> does not support TLS 1.3 while DC only works with TLS 1.3. The LURK
> extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead.
> As LURK was mentioned during the adoption period and until version 05 that
> should not cause any issues.
>
> Technologies only available for TLS 1.2 may be mentioned in the related
> work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to
> KEYLESS as it addresses the security concerns of KEYLESS.
>
>
> [Joe] KEYLESS is a deployed technology that is addressing some of the same
> use cases as Delegated credentials.  I'm not sure of the status of
> draft-mglt-lurk-tls13.
>
>
> <mglt>
> To respond to your question regarding the status of draft-mglt-lurk-tls13
> it is a work in progress. That said, I am a bit upset by the comment, so
> let me clarify my comment just in case I mis-interpreted something or I am
> completely wrong.
>
>

[Joe] I apologize if my comment came off a bit brusk.  I'm not sure if the
paper referenced is just applicable to TLS 1.2 or not, but if it is I can
see how the text could be misleading.  I think the security considerations
are reasonably clear since the extension is a 1.3 extension, however I
wouldn't hurt to mention that the problem manifests itself in TLS 1.3
because of 1.2 usage.  I'll let the authors take a crack at the comments
inline since they have more context.  I'm not sure if this document is the
place to have a discussion about LURK.


> Firstly, I tried to briefly describe the type of errors I think I noticed,
> so the co-authors do not need to parse all comments to get an idea of the
> types of errors. In this case, I had the impression that the subcert was
> initially intended to be an extension for TLS 1.2 and TLS 1.3, and the
> scope of TLS 1.2 has been removed in version 02 while not all text have
> been updated accordingly. It is a bit more than nits but I do not see
> this as a major concern.
>
> The related work section positions KEYLESS and subcert and think that is
> useful. My understanding is that KEYLESS only work for TLS 1.2 and for the
> server and subcert only works with TLS 1.3. When they shared a common TLS
> version, it was possible to use these 2 mechanisms together in a given TLS
> session.  Typically KEYLESS could host the private key of the DC or the
> X509 certificate and proceed to the appropriated cryptographic operations.
> This is at least my understanding of the text below:
>
> """
>
>    These two mechanisms can be complementary.  A server could use
>    credentials for clients that support them, while using [KEYLESS <https://tools.ietf.org/html/draft-ietf-tls-subcerts-09#ref-KEYLESS>] to
>    support legacy clients.  The private key for a delegated credential
>    can be used in place of a certificate private key, so it is important
>    that the Front-End and Back-End are parties that have a trusted
>    relationship.
>
> """
>
> Given that KEYLESS and DC work with different versions it seems hard to me
> that this could happen. I suspect there is an error and that KEYLESS is
> deployed or not seems to me a bit orthogonal to the fact that it does not
> achieve what is being written - or at least what I am understanding from
> the reading.
>
>

> I believe the case of using KEYLESS-like technologies is important to be
> mentioned and I believe that draft-mglt-tls13 while being work in progress
> fits the use case while KEYLESS does not.
> As mentioned in my text, I do not think adding LURK in the related work
> section represents a major update as the technology has been mentioned in
> the related work section during the adoption, and was there until version
> 05, and I do not recall this has raised any concerns at least on the
> mailing list. Digging on github I could only find [1], though I might have
> missed some discussions.
>
> For the sake of clarity and trying to address potential - and purely
> speculative - questions that may lie behind the initial question:
> * I think the related work section is useful as it clarifies concepts that
> had been confusing in the past. In addition, I have the impression that
> delegation may not be entirely deployed with DC and that complementary
> technology is needed - at least for the peer not supporting the extension.
> * I am not asking that KEYLESS be removed even if - as I understand -
> KEYLESS only address TLS 1.2. I think that is clearly stated.
> * I do not think the status of work in progress prevents soem work to be
> mentioned in a related work section. In some cases a draft status is
> sufficient for the IANA to assign code points.
> * I also believe that [draft-mglt-lurk-tls12] should be mentioned as it
> addresses some security concerns among others the signing oracle. It seems
> there are some misunderstanding around this [1].
>
> If there is anything you would like me to clarify, feel free to let  me
> know. I also believe that clarifications are provided in the inline
> comments.
>
> [1] https://github.com/tlswg/tls-subcerts/issues/30
>
>
> </mglt>
>
> There are other places where the extensions is mentioned together with TLS
> 1.2 that needs to be updated.
>
>
> [Joe] The only place I see TLS 1.2 mentioned is in the security
> consideration section in reference to the Bleichenbacher attack which is
> relevant if a server supports both TLS 1.3 and RSA key exchange with TLS
> 1.2.
>
> <mglt>
> That is at least one place I saw TLS 1.2 being mentioned. Note that the
> related work section also revealed some issue associated to TLS 1.2 without
> specifying the version. I suspected that these errors came from the initial
> support of TLS 1.2 in the beginning and wanted the co-authors to carefully
> review the draft in that perspective. I do not raise a comment to each of
> these and leave the co-authors to look at this carefully.
>
> It is correct that some servers may support two versions of TLS but I am
> not very familiar on how this is handled and operated. As a result I am not
> able to clearly mention if there is an error or not and this is why I kept
> the statement quite generic ( "Other places where the extension is
> mentioned together with TLS 1.2" explicitly or not..
>
> That said, I believe that if the section is entirely dedicated to the case
> where two versions are being co-hosted, I believe that should be at least
> clarified as well as other conditions such as (using the same key over the
> two versions, supporting signing and encryption for that key...). Again I
> am not very familiar with what is common practice in that scope. At least
> my perception of the text below is that the section was considering the use
> of DC in a context of TLS 1.2. I do not see this as a big issue either
> updating this section
>
> """
>
> When TLS 1.2 servers support RSA key exchange, ....
>
> """
> """
>
> For
>    TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
>    entity certificate, a hypothetical signature forgery attack would
>    allow forging a signature over a delegated credential.
>
> """
> </mglt>
>
> I also think that test vectors would be good as well as a link to a formal
> verification publication (if available).
>
> Please see all my comments inline, I hope they help.
>
> [Joe] Thanks,  I didn't get through these yet.  The authors should take a
> look.
>
> <mglt>
> Going through the comments is not very easy, this is why I tried to
> provide a brief overview. I am happy to do otherwise if that helps.
> </mglt>
>
>
> Yours,
> Daniel
>
> ----
>
>                      Delegated Credentials for TLS
>                        draft-ietf-tls-subcerts-09
>
> [...]
>
> 1.  Introduction
>
>    Typically, a TLS server uses a certificate provided by some entity
>    other than the operator of the server (a "Certification Authority" or
>    CA) [RFC8446] [RFC5280].  This organizational separation makes the
>    TLS server operator dependent on the CA for some aspects of its
>    operations, for example:
>
>    *  Whenever the server operator wants to deploy a new certificate, it
>       has to interact with the CA.
>
>    *  The server operator can only use TLS signature schemes for which
>       the CA will issue credentials.
>
>    These dependencies cause problems in practice.  Server operators
>    often deploy TLS termination services in locations such as remote
>    data centers or Content Delivery Networks (CDNs) where it may be
>    difficult to detect key compromises.  Short-lived certificates may be
>    used to limit the exposure of keys in these cases.
>
> <mglt>
> I believe it would be clearer to
> summarize the problem and link it to the
> use case. I would propose something
> around:
>
> These dependencies cause problems in
> practice, the management of key exposure
> necessarily requires an interaction with
> the CA.
>
> Typically server operators....
> </mglt>
>
>    However, short-lived certificates need to be renewed more frequently
>    than long-lived certificates.  If an external CA is unable to issue a
>    certificate in time to replace a deployed certificate, the server
>    would no longer be able to present a valid certificate to clients.
>    With short-lived certificates, there is a smaller window of time to
>    renew a certificates and therefore a higher risk that an outage at a
>    CA will negatively affect the uptime of the service.
>
>    To reduce the dependency on external CAs, this document proposes a
>    limited delegation mechanism that allows a TLS peer to issue its own
>    credentials within the scope of a certificate issued by an external
>    CA.  These credentials only enable the recipient of the delegation to
>    speak for names that the CA has authorized.  For clarity, we will
>    refer to the certificate issued by the CA as a "certificate", or
>    "delegation certificate", and the one issued by the operator as a
>    "delegated credential" or "DC".
>
> <mglt>
> From the text it is unclear why the
> signature scheme appears to be a
> constraint as well how it does not opens
> to some sort of downgrade attacks if
> left to the operator.
> </mglt>
>
>
> 3.  Solution Overview
>
> [...]
>
> 3.1.  Rationale
>
>    Delegated credentials present a better alternative than other
>    delegation mechanisms like proxy certificates [RFC3820] for several
>    reasons:
>
>    *  There is no change needed to certificate validation at the PKI
>       layer.
>
>    *  X.509 semantics are very rich.  This can cause unintended
>       consequences if a service owner creates a proxy certificate where
>       the properties differ from the leaf certificate.  For this reason,
>       delegated credentials have very restricted semantics that should
>       not conflict with X.509 semantics.
>
>    *  Proxy certificates rely on the certificate path building process
>       to establish a binding between the proxy certificate and the
>       server certificate.  Since the certificate path building process
>       is not cryptographically protected, it is possible that a proxy
>       certificate could be bound to another certificate with the same
>       public key, with different X.509 parameters.  Delegated
>       credentials, which rely on a cryptographic binding between the
>       entire certificate and the delegated credential, cannot.
>
>    *  Each delegated credential is bound to a specific signature
>       algorithm that may be used to sign the TLS handshake ([RFC8446]
>
>
>
>
> Barnes, et al.          Expires 28 December 2020                [Page 6]
>
> Internet-Draft        Delegated Credentials for TLS            June 2020
>
>
>       section 4.2.3).  This prevents them from being used with other,
>       perhaps unintended signature algorithms.
>
> <mglt>
> It is not clear to me why there is a
> "may be used". I suppose it concerns the
> use of the DC not the algorithm but that
> was confusing.
>
> I also believe that the specific
> signature algorithm to sign the
> delegated credential could be part of
> the rational.
> </mglt>
>
> 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>
>
> The private key for a delegated credential
>    can be used in place of a certificate private key, so it is important
>    that the Front-End and Back-End are parties that have a trusted
>    relationship.
>
>
>    Use of short-lived certificates with automated certificate issuance,
>    e.g., with Automated Certificate Managment Environment (ACME)
> <mglt>
> Management
> </mglt>
>    [RFC8555], reduces the risk of key compromise, but has several
>    limitations.  Specifically, it introduces an operationally-critical
>    dependency on an external party.  It also limits the types of
>
>
>
> Barnes, et al.          Expires 28 December 2020                [Page 7]
>
> Internet-Draft        Delegated Credentials for TLS            June 2020
>
>
>    algorithms supported for TLS authentication to those the CA is
>    willing to issue a certificate for.  Nonetheless, existing automated
>    issuance APIs like ACME may be useful for provisioning delegated
>    credentials.
>
> 4.  Delegated Credentials
>
>    While X.509 forbids end-entity certificates from being used as
>    issuers for other certificates, it is valid to use them to issue
>    other signed objects as long as the certificate contains the
>    digitalSignature KeyUsage ([RFC5280] section 4.2.1.3).  We define a
>    new signed object format that would encode only the semantics that
>    are needed for this application.  The credential has the following
>    structure:
>
>       struct {
>         uint32 valid_time;
>         SignatureScheme expected_cert_verify_algorithm;
>         opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
>       } Credential;
>
>    valid_time:  Time in seconds relative to the beginning of the
>       delegation certificate's notBefore value after which the delegated
>       credential is no longer valid.  This MUST NOT exceed 7 days.
> <mglt>
> I believe the behavior of the "verifying
> peer" should also be specified maybe
> with a reference.
>
> </mglt>
>
>    expected_cert_verify_algorithm:  The signature algorithm of the
>       credential key pair, where the type SignatureScheme is as defined
>       in [RFC8446].  This is expected to be the same as
>       CertificateVerify.algorithm sent by the server.  Only signature
>       algorithms allowed for use in CertificateVerify messages are
>       allowed.  When using RSA, the public key MUST NOT use the
>       rsaEncryption OID, as a result, the following algorithms are not
>       allowed for use with delegated credentials: rsa_pss_rsae_sha256,
>       rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
>
> <mglt>
> It is unclear whether the
> expected_cert_verify_algorithm and
> CertificateVerify.algorithm needs to be
> checked and what needs to be done in
> case of mismatch (with the RSA caveat).
> I believe that should be clarified.
>
> </mglt>
>
>    ASN1_subjectPublicKeyInfo:  The credential's public key, a DER-
>       encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280].
>
>    The delegated credential has the following structure:
>
>       struct {
>         Credential cred;
>         SignatureScheme algorithm;
>         opaque signature<0..2^16-1>;
>       } DelegatedCredential;
>
>    algorithm:  The signature algorithm used to verify
>       DelegatedCredential.signature.
>
> <mglt>
> I am wondering if any checks should be
> performed with the
> CertificateVerify.algorithm or if any
> algorithm would be acceptable. Unless I
> am missing something it seems a weak
> algorithm can be used - assuming the
> registry contains such weak algorithms.
> </mglt>
>
>
> Barnes, et al.          Expires 28 December 2020                [Page 8]
>
> Internet-Draft        Delegated Credentials for TLS            June 2020
>
>
>    signature:  The delegation, a signature that binds the credential to
>       the end-entity certificate's public key as specified below.  The
>       signature scheme is specified by DelegatedCredential.algorithm.
>
> [...]
>
> 4.1.1.  Server Authentication
>
>    A client which supports this specification SHALL send a
>    "delegated_credential" extension in its ClientHello.  The body of the
>    extension consists of a SignatureSchemeList:
>
>
>
>
>
> Barnes, et al.          Expires 28 December 2020                [Page 9]
>
> Internet-Draft        Delegated Credentials for TLS            June 2020
>
>
>       struct {
>         SignatureScheme supported_signature_algorithm<2..2^16-2>;
>       } SignatureSchemeList;
>
>    If the client receives a delegated credential without indicating
>    support, then the client MUST abort with an "unexpected_message"
>    alert.
>
>    If the extension is present, the server MAY send a delegated
>    credential; if the extension is not present, the server MUST NOT send
>    a delegated credential.  The server MUST ignore the extension unless
>    TLS 1.3 or a later version is negotiated.
>
>
>    The server MUST send the delegated credential as an extension in the
>    CertificateEntry of its end-entity certificate; the client SHOULD
>    ignore delegated credentials sent as extensions to any other
>    certificate.
>
>    The expected_cert_verify_algorithm field MUST be of a type advertised
>    by the client in the SignatureSchemeList and is considered invalid
>    otherwise.  Clients that receive invalid delegated credentials MUST
>    terminate the connection with an "illegal_parameter" alert.
>
> <mglt>
> I am wondering what would prevent any
> downgrade attacks if the
> SignatureSchemeList and
> signature_algorithms have two different
> sets of lists. My current understanding
> is that these extensions are handled
> independently, but I might be missing
> something.
>
> I am wondering if that would be
> appropriated to specify the signature of
> the CertificateVerify depending on the
> presence of the delegated credential - I
> mean the key used to generate it.
>
> </mglt>
>
> [...]
>
> 4.1.3.  Validating a Delegated Credential
>
>    On receiving a delegated credential and a certificate chain, the peer
>    validates the certificate chain and matches the end-entity
>    certificate to the peer's expected identity.  It also takes the
>    following steps:
>
>    1.  Verify that the current time is within the validity interval of
>        the credential.  This is done by asserting that the current time
>        is no more than the delegation certificate's notBefore value plus
>        DelegatedCredential.cred.valid_time.
>
>    2.  Verify that the credential's remaining validity time is no more
>        than the maximum validity period.  This is done by asserting that
>        the current time is no more than the delegation certificate's
>        notBefore value plus DelegatedCredential.cred.valid_time plus the
>        maximum validity period.
>
>    3.  Verify that expected_cert_verify_algorithm matches the scheme
>        indicated in the peer's CertificateVerify message and that the
>        algorithm is allowed for use with delegated credentials.
>
> <mglt>
> I am wondering if a reference to specify
> what allowed would not be needed unless
> it means advertised in the extension.
>
> </mglt>
>
>    4.  Verify that the end-entity certificate satisfies the conditions
>        in Section 4.2.
>
>    5.  Use the public key in the peer's end-entity certificate to verify
>        the signature of the credential using the algorithm indicated by
>        DelegatedCredential.algorithm.
>
>    If one or more of these checks fail, then the delegated credential is
>    deemed invalid.  Clients and servers that receive invalid delegated
>    credentials MUST terminate the connection with an "illegal_parameter"
>    alert.  If successful, the participant receiving the Certificate
>    message uses the public key in the credential to verify the signature
>    in the peer's CertificateVerify message.
>
> [...]
>
> 7.  Security Considerations
>
> [...]
>
> 7.6.  The Impact of Signature Forgery Attacks
>
>    When TLS 1.2 servers support RSA key exchange, they may be vulnerable
>    to attacks that allow forging an RSA signature over an arbitrary
>    message [BLEI].  TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a
>    mitigation strategy requiring careful implementation of timing
>    resistant countermeasures for preventing these attacks.  Experience
>    shows that in practice, server implementations may fail to fully stop
>    these attacks due to the complexity of this mitigation [ROBOT].  For
>    TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
>    entity certificate, a hypothetical signature forgery attack would
>    allow forging a signature over a delegated credential.  The forged
>    credential could then be used by the attacker as the equivalent of a
>    man-in-the-middle certificate, valid for 7 days.
>
> <mglt>
> I do not see the relevance to TLS 1.3.
> </mglt>
>
>    Server operators should therefore minimize the risk of using DC-
>    enabled end-entity certificates where a signature forgery oracle may
>    be present.  If possible, server operators may choose to use DC-
>    enabled certificates only for signing credentials, and not for
>    serving non-DC TLS traffic.  Furthermore, server operators may use
>    elliptic curve certificates for DC-enabled traffic, while using RSA
>    certificates without the DelegationUsage certificate extension for
>    non-DC traffic; this completely prevents such attacks.
>
>    Note that if a signature can be forged over an arbitrary credential,
>    the attacker can choose any value for the valid_time field.  Repeated
>    signature forgeries therefore allow the attacker to create multiple
>    delegated credentials that can cover the entire validity period of
>    the certificate.  Temporary exposure of the key or a signing oracle
>    may allow the attacker to impersonate a server for the lifetime of
>    the certificate.
>
>
> ------------------------------
> *From:* TLS <tls-bounces@ietf.org> on behalf of Salz, Rich <rsalz=
> 40akamai.com@dmarc.ietf.org>
> *Sent:* Monday, June 29, 2020 12:00 PM
> *To:* Joseph Salowey <joe@salowey.net>et>; <tls@ietf.org> <tls@ietf.org>
> *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
>
>
> I’d still like to see test vectors.
>
>