Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Eric Rescorla <ekr@networkresonance.com> wrote:

> Hi folks,
>
> I've been going through the list discussion on
> draft-ietf-tls-renegotiation and wanted to try to close on some of the
> edits people have proposed.
>
> 1. Replace "cipher suite" with magic cipher suite value (MCSV)
>    throughout.
>
> 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly
stating
>    4346 and 2246? ISTM we already transitively update them, but I don't
>    care either way.
>
> 3. Rewrite the introduction along the lines suggested by Marsh Ray,
>    Nicolas Williams, David-Sarah Hopwood, and others to more accurately
>    capture the entities which are being spliced here. I will propose
>    new text on the list.
>
> 4. Channel bindings: replace the end of S 1. with:
>
>    "The data used in the extension is similar to, but not the same as,
the
>    channel binding data used in [I-D.altman-tls-channel-bindings],
however
>    this extension is not a generic-purpose RFC 5056 channel binding
>    facility."
>
>    Nico, did you have other text you wanted?
>
> 5. Explicitly state that this extension also applies to DTLS and
>    that the same normativity levels apply.
>
> 6. Explicitly state that this extension may also be used with
>    SSLv3 (we don't have any authority to update SSLv3 in any
>    way but we can certainly say that there is no technical
>    obstacle.)

I would request that this needs to include sufficient technical details
e.g. the size of the verify_data values etc.

>
> 7. Clarify that RI MUST be generated in all rehandshakes, per the
>    issue Martin raised earlier and proposed resolution by Marsh
>    and Nelson.
>
> 8. Rewrite the introduction to more clearly elucidate
>    the impact on app-level protocols. As Chris Newman has pointed
>    out it currently apples primarily to HTTPS, but we should have
>    some non-HTTPS text. I will propose new text on the list.
>
> 9. Rewrite the section about identity changes in Security Considerations.
>    I'll propose new text on the list.

I additionally request guidance be included in Section 5 on safe probing of
Servers during initial connection to prevent outages in environments that
may include extension intolerant servers as per:

Note :  In cases where a ClientHello protocol behavior change from not
sending extensions to sending extensions is a risk where legacy Servers may
exist that are extension intolerant then the Client MAY mitigate this risk
on initial connection by sending the TLS cipher suite
"TLS_RENEGO_PROTECTION_REQUEST" and SHOULD NOT send the
"renegotiation_info" extension unless the Client is sending other
extensions.

SA http://www.imc.org/ietf-tls/mail-archive/msg11082.html

- Thanks
- Mick Gray
- IBM

> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls