<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote:<br>
> So I plan to start the vote soon for merging PR#8096 and backporting it to<br>
> 1.1.1. This is a breaking change as previously discussed.<br>
> <br>
> My proposed vote text is as follows. Please let me know asap of any feedback.<br>
> Otherwise I will start the vote soon.<br>
> <br>
> "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and<br>
> SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake<br>
> message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and<br>
> SSL_CB_HANDSHAKE_END)."<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Is it important that both sides agree what an "exchange" is?<br></div><div><br></div><div>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.</div><div><br></div><div>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.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This will only cover the key update currently? Does that come with<br>
some parameter telling which kind of handshake is happening? If<br>
not, is it more useful to just say that a key update is happening?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>David</div></div></div>