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 protected]> Sent: Thursday, January 24, 2019 3:23 PM To: Subodh Iyengar Cc: Martin Thomson; [email protected] 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> on behalf of Martin Thomson <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 15, 2019 7:39:44 PM To: [email protected]<mailto:[email protected]> 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 protected]<mailto:[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=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e= _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> 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=>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
