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

Ilari Liusvaara <> Wed, 16 September 2020 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 169DA3A1225 for <>; Wed, 16 Sep 2020 05:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Qyl4-07AXOw for <>; Wed, 16 Sep 2020 05:28:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B4003A1224 for <>; Wed, 16 Sep 2020 05:28:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCD62684F1 for <>; Wed, 16 Sep 2020 15:28:47 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 8oww8LRurbs9 for <>; Wed, 16 Sep 2020 15:28:47 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9C7007A for <>; Wed, 16 Sep 2020 15:28:46 +0300 (EEST)
Date: Wed, 16 Sep 2020 15:28:45 +0300
From: Ilari Liusvaara <>
To: "<>" <>
Message-ID: <20200916122845.GA1653297@LK-Perkele-VII>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
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: Wed, 16 Sep 2020 12:28:52 -0000

On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote:
>  Hi Nick,
> Thanks for the response and I apologize for my delayed response. However I
> still have two major concerns regarding the current proposed text:
> Mentioning keyless as the only solution complementary to DC still seems to
> me technically inaccurate. With KeylessSSL, the key server  receives a hash
> based on randoms and ECDH parameters. The hash used in TLS 1.3 is different
> than in TLS 1.2 - when hashes are involved in the signature scheme - so
> Keyless would not work in this case - at least as far as I understand - and
> significant changes are need to make it work in TLS 1.3.

The way I understand Keyless is as generic mechanism. The reason why the
Keyless paper did not discuss TLS 1.3 was that TLS 1.3 was very early
draft, and thus in significant flux, when the Keyless paper was published.

Extending the signed-DH variant of Keyless to work with TLS 1.3 is
straightforward task. And there are already production implementations.

> It seems to me technically more accurate to mention the effort performed on
> TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context. On
> the other hand, not mentioning it seems to me misleading. I also think it
> is misleading to not mention an effort that addresses the signing oracle
> security vulnerabilities associated to keylessSSL, leading to the
> impression that such attacks are inherent to the key server architecture -
> with a dedicated section 7.6. I understand, though,
> that  draft-mglt-lurk-tls13 is not a commercial product and still an
> ongoing effort.
> So far - unless I am missing them - I have not seen any technical
> justification for not mentioning that justify the single mention of
> keylessSSL and temptative of (non technical) procedural explanations do not
> seem valid ( see in line ).

IIRC, some analysis of Keyless type scheme found some security issues.
All but one was associated with RSA variant, and thus not a concern
with using TLS 1.3. The remaining one involved interaction with gQUIC.
AFAIK, the security issues with gQUIC that led to the problem have been
fixed (and iQUIC never had the problem to begin with).

And the way TLS 1.3 signatures are constructed, that harmful
interaction with gQUIC could trivially be prevented (preventing
that interaction with TLS 1.2 is a bit trickier, but still feasible).

The section 7.6 stuff is only relevant to the RSA variant. There are
solid ways to prevent those issues. For example:

1) Use ECC keys.
2) Use interface which only has message for signed-DH variant.

Based on data I have seen, there is virtually no reason to support
RSA in TLS 1.2 or 1.3. I do not have seen corresponding data for TLS
1.0 and 1.1.

> Another concern I have - at least my understanding of it - is that DC is
> subject to downgrade attacks. Typically the TLS operator chooses the
> signature used by the DC to authenticate the server and this signature
> scheme can be weaker than the signature scheme provided by the CA. This
> prevents a content owner to enforce a (strong) level of authentication and
> - in the future - the use of deprecated/weak signature schemes. The threat
> model here is on the content owner perspective to ensure its website is
> strongly authenticated. The fact that the client can remove weak signature
> schemes does not seem sufficient as nothing seems to force the client to
> only use strong authentication with SignatureSchemeList potentially
> appearing in clear. The threat model you seem to refer to is the client to
> choose a strong authentication, but I think that is a bit different.

The content owner can pick what algorithms he signs DCs for. Say that
the content owner has ECDSA P-384 certificate and wants comparable
authentication strength. Then he only signs DCs for ECDSA P-384 and
Ed448. This way there is no downgrade below 192-bit level.

And in case of sudden cryptographic advance reducing strength of some
algorithm badly enough, that algorithm can be dropped quickly.