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

Daniel Migault <> Mon, 21 September 2020 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D61AC3A0EC1 for <>; Mon, 21 Sep 2020 06:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 764GXqMngsxI for <>; Mon, 21 Sep 2020 06:30:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CBEF3A08CD for <>; Mon, 21 Sep 2020 06:30:10 -0700 (PDT)
Received: by with SMTP id b123so8095309vsd.10 for <>; Mon, 21 Sep 2020 06:30:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9FFtFNI5ZjbGB6iy+jxM+AWDF9SwiHMkQW2ukX8nPA=; b=PA5n2oY0T8c8nDSr1Jkj1G/dBRfkMzawR4BNSUCHWqJYBx/P6/Oqx1ga6rP39Vt/YI sxvFRPH8xtlLI4f7H3UH9ldza/Jsq0qtLrbLcIP3KBsy3R81jWRYlyhxHmNqYBDtVCqN rZ8fXZqO3HvOm3szwOcpvDscIYJX5QPyV9WX1PUD3K2I0zj/0hcG7+g6RGIgtEnLjfCf 8AHzfIoAQ85Yx0H7TEw6KkQLhBmzNvmJ7Ua4PWOsVbAH/J9DceXmClbnaQzZ8V2Ja5eH g8Ht4IlFhnliPvDLDKti84NKQFHc+b9vIs+Vt2GyPcpsgRKKXmnCScph1u5/WdzScI63 hOXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9FFtFNI5ZjbGB6iy+jxM+AWDF9SwiHMkQW2ukX8nPA=; b=XumwWlci/Dh8D4V/m41l7K5AG9U6UTXNygv/4Y/WiYb/5TjUaREjdlO4UPD2HwxFwd wss8gckIIiG/RN+jHWAV7CqkN5SmtvW3AevRBYhCkTB6nUP7HIjnpEJhbikdpPASMJm0 dAtfTepWHIndeUxu17yAB7DOKn9RFokhjUalQ9yfpNhKbsSOag0Vurfsib5xO1ztqdvv Hxjvy9y78yiHaDNXbkQo/2YxP5brz01nQfwvcrCXdt0RyoJsNZ7awlgMX22IEKYv8CsX dePb62rGnp+J+13tFYMGRPdDE9qWGdXai5THeSLdwHwl7QrB4pK2kViUkn5oJEt5i+iD yZfA==
X-Gm-Message-State: AOAM532BXLzRGbzILelKMc4kJiQK4zxpUK5eRpB/+tIEEzRfbZiS7/IY jFmyeXimSXZtPLPj4nytzpz9GCKrwWGUgR6t1ps=
X-Google-Smtp-Source: ABdhPJzaYw5stk36qowsdCueLBmAFk00MAiDZ3pa7IM+HgnfZDHy3eN+I7skbwBONj/EFh8Ae9KLtk/FlE6CuPbULnM=
X-Received: by 2002:a67:d219:: with SMTP id y25mr26645121vsi.29.1600695009276; Mon, 21 Sep 2020 06:30:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <20200916122845.GA1653297@LK-Perkele-VII>
In-Reply-To: <20200916122845.GA1653297@LK-Perkele-VII>
From: Daniel Migault <>
Date: Mon, 21 Sep 2020 09:29:57 -0400
Message-ID: <>
To: Ilari Liusvaara <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000006bf70205afd2d989"
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: Mon, 21 Sep 2020 13:30:13 -0000

Hi Ilari,

Thanks for the feed back. PLease see my comments inline.

On Wed, Sep 16, 2020 at 8:29 AM Ilari Liusvaara <>

> 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.

Well the text mentions a remote signing mechanism - I understand as a
generic mechanism - followed by a reference [KEYLESS]. That reference says:
Our work focuses specifically on the TLS handshake
proxying system implemented by CloudFlare in their Keyless
SSL product
So I am not convinced Keyless can be interpreted as a generic mechanism as
opposed to a specific commercial solution.

Note that I am not against KEYLESS being mentioned. I am just raising the
issue this is not the only mechanism. My request is that, to appear
generic multiple mechanisms could be mentioned [keyless,
draft-mglt-lurk-tls12, draft-mglt-lurk-tls13]. At least I do not see how
mentioning the other mechanisms would affect the genericity or the
understanding. Note also these mechanisms were mentioned in previous
versions of the draft.

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.

I am not saying that is hard to extend Keyless to TLS 1.3 nor to the TLS
client side. I am just saying the reference does not seems to do what is
described in the section. If there are already production implementations
of Keyless with TLS 1.3 the ref might be updated I agree. I am happy to
know which reference you would have in mind.
Again I am not discussing whether Keyless should or should not be
mentioned. I am willing to have other efforts being mentioned.

> 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).
The vulnerability I had in mind was the signing oracle where Keyless signs
without context any provided hash value together with randoms.
It is difficult for me to comment on the TLS 1.3 version of Keyless since I
am not aware of it. The updated reference might help. That said, if the
hash is being sent to the key server, the situation is not improved in
terms of security over TLS 1.2. If the full handshake context is provided,
then this would represent a significant change compared to the version used
for TLS 1.2 - at least in term of performances.  I also imagine that
Ed25519 will take the full handshake.
Even if  the full handshake is provided, probably more thoughts are needed
to see if that is sufficiently secure for both the TLS client or TLS server
as well as how anti-replay protection is implemented.
So to sum up further analysis is needed to be able to claim that keyless in
TLS 1.3 does not have vulnerabilities and effectively represents an
improvement over Keyless with TLS 1.2
Again I am not discussing whether Keyless should or should not be
mentioned. I am willing to have other efforts to be mentioned.

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.

Just for clarification. does 2) means not to use in TLS 1.2 RSA
authentication ? 1) seems to correspond to the modern cryptography [1]. I
am unaware of the data you have in mind, but it seems to me that the use of
RSA signature remains because of legacy or not-yet up-to-date clients.
Overall I am not disagreeing with your statement but it seems until RSA is
not deprecated vulnerabilities associated to RSA will remain.  Maybe I am
missing something.


> > 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.
Looks this addresses my concern. The content owner controls the algorithm
that is mentioned in the subject public key info. Thanks!

> -Ilari
> _______________________________________________
> TLS mailing list

Daniel Migault