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

[Daniel Migault <[e-mail]>]

Hi Ilari,

Thanks for the feed back. PLease see my comments inline.
Yours,
Daniel

On Wed, Sep 16, 2020 at 8:29 AM Ilari Liusvaara <[e-mail]>
wrote:

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


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

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.


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

> 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).
>
>
<mglt>
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.
</mglt>

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

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

[1] https://wiki.mozilla.org/Security/Server_Side_TLS
</mglt>


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


>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson