Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

[Subodh Iyengar <[e-mail]>]

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 <[e-mail]> on behalf of Watson Ladd <watson=[e-mail]>
Sent: Tuesday, January 15, 2019 5:13:17 PM
To: [e-mail]
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
[e-mail]
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=