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]> 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]> on behalf of Martin Thomson < > [email protected]> > *Sent:* Tuesday, January 15, 2019 7:39:44 PM > *To:* [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] > > 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] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
