<wearing Area Director hat>

I agree that minimal risk of breaking things that currently work is
important for timely deployment of the fix.  The proposed change seems
to address many of the concerns raised so far, and significantly
improves on the -00 draft.

If it's quite unlikely to break things that currently work, and
reasonably simple to implement (e.g., avoids the need for fall-back to
extension-less handshake, which can't be necessarily implemented by
the TLS library -- this is a big change to the -00 draft), I'd say
we're reaching "good enough", and timely publication is more important
than the exact bits.

Unless the WG believes these goals are not actually met (that is, this
still could break too many things, or is excessively complex to
implement/deploy), I'd like to see an updated draft soon, and start
IETF Last Call.

Best regards,
Pasi

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> ext Eric Rescorla
> Sent: 26 November, 2009 00:35
> To: tls@ietf.org
> Subject: [TLS] Avoiding first use of RI in ClientHello
> 
> 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