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

From: Watson Ladd <[email-masked]>
Date: Tue, 15 Jan 2019 17:13:17 -0800

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

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 16 Jan 2019 02:35:20 +0000

Thanks for bringing these up Watson

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.

That would be great.

Subodh

________________________________
From: TLS <[email-masked]> on behalf of Watson Ladd <watson=[email-masked]>
Sent: Tuesday, January 15, 2019 5:13:17 PM
To: [email-masked]
Subject: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

Dear TLS WG,

Sincerely,
Watson

_______________________________________________
TLS mailing list
[email-masked]
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=

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2019 14:39:44 +1100

> Usually the negotiation happens during the processing of the client hello.

I don't think that the problem here is a code problem.  It's an operational one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be made in isolation.  You decide to flip the switch and flip it.  But if you are doing delegated credentials, deploying a new version depends on having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new credentials.  And that assumes that all the necessary stores are keyed correctly (though this highlights the case where that might not happen), and the code has been written.  It's not that it's impossible, but more that it complicates what was previously uncomplicated.

As you say, the decision to use a delegated credential is fairly simple.

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 16 Jan 2019 07:54:36 +0000

I don't feel too strongly about the tls version binding and I'd be fine with removing it to favor operational simplification.

Subodh

________________________________
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Tuesday, January 15, 2019 7:39:44 PM
To: [email-masked]
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e=

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 24 Jan 2019 15:23:20 -0800

I'm also fine with removing the field and would welcome a PR to that effect.

Putting in a version to protect a DC from future cross-protocol attacks
that exploit TLS 1.3 smells a bit like over-engineering anyway.

Nick

On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar <[email-masked]> wrote:

> I don't feel too strongly about the tls version binding and I'd be fine
> with removing it to favor operational simplification.
>
>
> Subodh
> ------------------------------
> *From:* TLS <[email-masked]> on behalf of Martin Thomson <
> [email-masked]>
> *Sent:* Tuesday, January 15, 2019 7:39:44 PM
> *To:* [email-masked]
> *Subject:* Re: [TLS] Version pinning and indicating the signing algorithm
> in draft-ietf-tls-subcerts-02
>
> In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be
> made in isolation.  You decide to flip the switch and flip it.  But if you
> are doing delegated credentials, deploying a new version depends on having
> a fallback in place for that version, or getting the vendor of delegated
> credentials to start supplying new credentials.  And that assumes that all
> the necessary stores are keyed correctly (though this highlights the case
> where that might not happen), and the code has been written.  It's not that
> it's impossible, but more that it complicates what was previously
> uncomplicated.
>
> https://www.ietf.org/mailman/listinfo/tls
>