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

From: Subodh Iyengar <[email-masked]>
Date: Thu, 14 Feb 2019 00:59:43 +0000

Watson put up a PR https://github.com/tlswg/tls-subcerts/pull/21. I'm going to merge it tomorrow if there's no other feedback on it.
[https://avatars3.githubusercontent.com/u/1123811?s=400&v=4]<https://github.com/tlswg/tls-subcerts/pull/21>

Remove protocol from the structure by wbl · Pull Request #21 · tlswg/tls-subcerts<https://github.com/tlswg/tls-subcerts/pull/21>
As discussed in https://mailarchive.ietf.org/arch/msg/tls/h6DiWQvw7Cc0TXUtc7fNfB0fFNg and subsequent.
github.com

Subodh
________________________________
From: Nick Sullivan <[email-masked]>
Sent: Thursday, January 24, 2019 3:23 PM
To: Subodh Iyengar
Cc: Martin Thomson; [email-masked]
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

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

On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> 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.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[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=
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Q7cYq4juf3o-0YWxZtuLP7YJ8Kuwm-RSfp3YaF9dUn8&s=5P2RjQvDuXZivTnTQ3VNB0Gw49CwSQM97-EiDA9rmck&e=>