Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote: > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx wrote: > > > On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote: > > > So I plan to start the vote soon for merging PR#8096 and backporting it > > to > > > 1.1.1. This is a breaking change as previously discussed. > > > > > > My proposed vote text is as follows. Please let me know asap of any > > feedback. > > > Otherwise I will start the vote soon. > > > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START > > and > > > SSL_CB_HANDSHAKE_END)." > > > > What exactly is a post-handshake message exchange? Do the NewSessionTicket > sent by the server at the beginning count as the part of the handshake? Are > they each separate post-handshake exchanges? Are all of them together one > exchange? Conversely, what happens when you receive that NewSessionTicket > as a client? I don't think we should try to get into the business of demarcating the start and end of post-handshake exchanges. (In particular, the NewSessionTickets are formally not grouped with anything, whether the initial handshake or each other.) > When you send a KeyUpdate with key_update_requested, is the reply you > expect part of the exchange or separate? What if the peer coalesced them to > avoid DoS problems? Conversely, if you receive a KeyUpdate with > key_update_requested, is your reply part of the exchange? What if you > coalesced them to avoid DoS problems? > > What if I send a CertificateRequest, but the other side sends me a > KeyUpdate with key_update_requested before responding with Certificate, so > I respond with my own KeyUpdate? What and how many exchanges are there? > > Is it important that both sides agree what an "exchange" is? > > What I'm getting at here is that "post-handshake exchange" does not seem to > be a meaningful construct to the protocol. I would thus advocate not > signaling START/END things to begin with. That way, if TLS 1.4 comes by and > shuffles around again, we don't repeat this adventure. +1 > I think one clear conclusion from this incident is that this sort of > low-level API should be avoided, or people will use them in finicky ways > that break unexpectedly when you change things. Better defer such > mechanisms to when concrete use cases come up, and then implement direct > APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback > hadn't existed, OpenSSL would hopefully have learned sooner that > SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided > today's TLS 1.3 KeyUpdate intolerance in the ecosystem.) > > > > This will only cover the key update currently? Does that come with > > some parameter telling which kind of handshake is happening? If > > not, is it more useful to just say that a key update is happening? > > > > There's already a message callback. Why not just use that? It's unclear to > me why anyone would want to know when KeyUpdates happen anyway, aside from > low-level logging and debugging. The message callback works fairly well for > such things. +1 -Ben ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote: > I think one clear conclusion from this incident is that this sort of > low-level API should be avoided, or people will use them in finicky ways > that break unexpectedly when you change things. Better defer such > mechanisms to when concrete use cases come up, and then implement direct > APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. I have to agree to that. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx wrote: > On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote: > > So I plan to start the vote soon for merging PR#8096 and backporting it > to > > 1.1.1. This is a breaking change as previously discussed. > > > > My proposed vote text is as follows. Please let me know asap of any > feedback. > > Otherwise I will start the vote soon. > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START > and > > SSL_CB_HANDSHAKE_END)." > What exactly is a post-handshake message exchange? Do the NewSessionTicket sent by the server at the beginning count as the part of the handshake? Are they each separate post-handshake exchanges? Are all of them together one exchange? Conversely, what happens when you receive that NewSessionTicket as a client? When you send a KeyUpdate with key_update_requested, is the reply you expect part of the exchange or separate? What if the peer coalesced them to avoid DoS problems? Conversely, if you receive a KeyUpdate with key_update_requested, is your reply part of the exchange? What if you coalesced them to avoid DoS problems? What if I send a CertificateRequest, but the other side sends me a KeyUpdate with key_update_requested before responding with Certificate, so I respond with my own KeyUpdate? What and how many exchanges are there? Is it important that both sides agree what an "exchange" is? What I'm getting at here is that "post-handshake exchange" does not seem to be a meaningful construct to the protocol. I would thus advocate not signaling START/END things to begin with. That way, if TLS 1.4 comes by and shuffles around again, we don't repeat this adventure. I think one clear conclusion from this incident is that this sort of low-level API should be avoided, or people will use them in finicky ways that break unexpectedly when you change things. Better defer such mechanisms to when concrete use cases come up, and then implement direct APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback hadn't existed, OpenSSL would hopefully have learned sooner that SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided today's TLS 1.3 KeyUpdate intolerance in the ecosystem.) > This will only cover the key update currently? Does that come with > some parameter telling which kind of handshake is happening? If > not, is it more useful to just say that a key update is happening? > There's already a message callback. Why not just use that? It's unclear to me why anyone would want to know when KeyUpdates happen anyway, aside from low-level logging and debugging. The message callback works fairly well for such things. David ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote: > So I plan to start the vote soon for merging PR#8096 and backporting it to > 1.1.1. This is a breaking change as previously discussed. > > My proposed vote text is as follows. Please let me know asap of any feedback. > Otherwise I will start the vote soon. > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > SSL_CB_HANDSHAKE_END)." This will only cover the key update currently? Does that come with some parameter telling which kind of handshake is happening? If not, is it more useful to just say that a key update is happening? Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
So I plan to start the vote soon for merging PR#8096 and backporting it to 1.1.1. This is a breaking change as previously discussed. My proposed vote text is as follows. Please let me know asap of any feedback. Otherwise I will start the vote soon. "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_END)." Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Release strategy updates
On 14/01/2019 15:21, Matt Caswell wrote: > > > On 21/09/2018 14:19, Matt Caswell wrote: >> I am very concerned about stability of our API moving forwards. There >> are various discussions about changing the version number to 1.2.0 (or >> possibly 2.0.0) - which according to our versioning scheme would allow >> breaking changes. Whilst this is true I think we need to be very wary >> about "opening the flood gates" for breaking changes. >> >> The move from 1.0.x to 1.1.0 was hard on our users and we should avoid >> that again. >> >> With that in mind I have opened the following PR (based largely on >> wording suggested by Viktor): >> >> https://github.com/openssl/web/pull/82 >> >> At the same time I have taken the opportunity to clean up some >> out-of-date stuff in the release strategy. >> >> This is independent of the semantic versioning discussion which may >> itself see further changes being made to the release strategy. >> >> Thoughts? >> >> Matt >> > > A somewhat tardy follow up on this...I updated this PR with the latest > comments > so please take a look. Another update to the PR. Most significantly I merged the commits from PR 104 into this one. Please take another look. In particular I guess the most controversial bit is the the stability policy words at the end. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
