Thanks for bringing these up Watson
>The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.
Usually the negotiation happens during the processing of the client hello.
The certificate decision gets made a later. Is there a specific implementation
detail
you're concerned about.
I think the negotiation of TLS version should be done first before deciding to
use
DCs, and this needs to be done anyway because DCs are only valid TLS 1.3 and
higher.
The existing set of creds would become invalid with a future version of TLS..
The method by which the TLS terminating server receives the DC is out of scope
of this
document, however I hope people implement some sort of structure to their
backend like
DC_objs = [ DC_obj1, DC_obj2,. ...]
DC_obj = { tls_version, private_key, DC structure, .etc.. }
which would make it so that they would automatically get new creds when they
are updated.
Also there is the option of falling back to LURK style service if the DC
doesn't exist. I wonder
if there is anything I'm missing here. The original rationale around DCs being
bound to version
was to be able to preventing some attack on the current version of TLS which
might expose an
oracle to be used against a future version of TLS that might fix it (like
DROWN). If we think that this is not super
useful since we will never have oracle attacks in TLS 1.3, we can remove it as
well.
> The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.
That would be great.
Subodh
________________________________
From: TLS <[email protected]> on behalf of Watson Ladd
<[email protected]>
Sent: Tuesday, January 15, 2019 5:13:17 PM
To: [email protected]
Subject: [TLS] Version pinning and indicating the signing algorithm in
draft-ietf-tls-subcerts-02
Dear TLS WG,
While we were implementing delegated credentials we came up with the
following two problems. I thank David Benjamin for communicating the
first to me.
The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.
The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.
Sincerely,
Watson
_______________________________________________
TLS mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=ZnSY03FUuGDkpTjaYw9S-739-JBe-iqsIaeiu32GMvU&s=sxKHoBLptrk0e_hub5oKvfRWf1akiS095tuHtXLCZ38&e=
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
