Eric,

I think this is a great approach and in line with recent proposals.
I prefer the RI extension without the verify data for reasons previously
stated on the list.

/Stefan


On 09-11-25 11:35 PM, "Eric Rescorla" <ekr@networkresonance.com> wrote:

> Folks,
> 
> I wanted to try to resolve what I see as the major technical concern
> people have about draft-ietf-tls-renegotiation-00, namely that the
> client cannot offer secure renegotiation and be sure that it won't
> cause a connection failure with a downrev (extension noncompliant)
> server.
> 
> There's been a lot of discussion of whether this is a serious problem,
> but it's clear that minimal risk of breaking things that currently
> work (which some folks think requires not using extensions in the
> initial ClientHello) is important for the timely deployment of the
> fix, and with the current draft, that may require fall-back to
> extension-less handshake.
> 
> It's unclear how often such fall-back logic would actually be needed,
> and I do find Nelson's "tough love" approach here sort of appealing,
> but it does seem to be a problem that you don't necessarily know for sure
> whether you need it or not until you've actually shipped the product
> with extensions, and possibly broken applications that currently work.
> It's especially concerning that fall-back can't be implemented reliably
> inside the TLS library, e.g., if you just get a filehandle, so changes
> to the app logic are required.
> 
> 
> The rest of this message describes a simple modification [*] to
> draft-ietf-tls-negotiation which I think addresses this compatibility
> issue without requiring fall-back.
> 
> The idea is to use a magic cipher suite to signal that the client can
> securely renegotiate (as described in
> draft-mrex-tls-secure-renegotiation).  However, the server treats this
> EXACTLY as if the client had offered an empty RI extension, and
> responds with its own RI extension (or if it doesn't implement the
> full extension framework, just adds a known byte string to the end of
> the ServerHello). In other words:
> 
> 
> Client                                          Server
> ------------------------------------------------------
> ClientHello + TLS_RENEGO_PROTECTION_REQUEST ->
>                              <- ServerHello + Empty RI
> 
> 
> At this point, the client now knows that the server supports secure
> renegotiation and can simply send RI in any renegotiation handshake
> (and if the client doesn't implement the full extensions framework, it
> could just add a known byte string to the end of the ClientHello,
> without requiring full extension support). Note that this is
> reminiscent of the SSLv2->SSLv3 transition where clients would
> initially offer backward compatibility handshakes but once they knew
> the server was SSLv3-capable would offer the new ClientHello.
> 
> 
> What about 5246 and unsolicited extensions?
> As far as I can tell, the major argument against using extensions
> for S->C signalling is the 5246 prohibition against the server providing
> unsolicited extensions. However, that was clearly intended to prevent
> the server from sending extensions the client didn't expect and
> that's not the case here. Moreover, we're updating 5246 so we can relax
> the restriction for this extension (though I would think not in general).
> 
> 
> What about not putting the verify data in the extension?
> I think that issue is separable from the question of how we signal
> support, so would like to deal with it separately. (It seems this
> won't make any difference for the bigger questions like can deploying
> the fix break things that currently work, or whether you can implement
> the fix purely inside the TLS library)
> 
> 
> What about SSLv3?
> Obviously, the ClientHello is compatible with SSLv3.  (and the magic
> cipher suite can be offered even in SSLv2 backward compatible
> hello---ugh!). Although SSLv3 does not have the TLS extension
> framework, we could also specify that the server (once it sees the
> magic cipher suite indicating the client supports this draft) just
> appends the relevant fixed-length byte string to the end of the
> ServerHello.
> 
> 
> What do people think about this approach?
> 
> -Ekr
> 
> [*] I didn't invent this approach, I'm just reproposing it to try to focus
> discussion.
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls