Subject: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Dec 2009 10:23:50 -0800

While following the numerous threads, it seems that some people are advocating adding MCSV to RI, while others are advocating RI by itself (no MCSV), while others are advocating MCSV by itself (instead of RI).

Can people please be more specific which proposal they are advocating? It greatly affects the conversation. Thanks!

--Paul Hoffman, Director
--VPN Consortium

---

From: Marsh Ray <[email-masked]>
Date: Thu, 10 Dec 2009 12:53:21 -0600

Paul Hoffman wrote:
> While following the numerous threads, it seems that some people are
> advocating adding MCSV to RI, while others are advocating RI by
> itself (no MCSV), while others are advocating MCSV by itself (instead
> of RI).

> Can people please be more specific which proposal they are
> advocating? It greatly affects the conversation. Thanks!

I am advocating draft-ietf-tls-renegotiation which includes MCSV.

I don't think anyone still is still advocating "RI without MCSV".

My interpretation of draft-mrex-tls-secure-renegotiation is that it uses
MCSV in Client Hello and a fixed empty extension in Server Hello. Martin
may describe it differently.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 21:50:16 +0100 (MET)

Paul Hoffman wrote:
> advocating adding MCSV to RI, while others are advocating RI by itself
> (no MCSV), while others are advocating MCSV by itself (instead of RI).
> 
> Can people please be more specific which proposal they are advocating?
> It greatly affects the conversation. Thanks!

Provided that we mean this:

(1) RI by itself (no MCSV) = draft-rescorla-tls-renegotiation-00

(2) RI with MCSV = draft-ietf-tls-renegotiation-01

(3) MCSV (no RI) = draft-mrex-tls-secure-renegotiation-03

I'm firmly against (1)

I prefer (3)

I could live with (2) if the requirements for MSCV were tightened to be
as non-disruptive as possible.  I have been trying to explain what
those requirements are.  The overloaded semantics of TLS extension RI
create special cases where some implementors have been advocating
inappropriate behaviour for implementations in backwards interop
scenarios.

For some implementors, non-disruptive backwards interop provisions
are familiar, and they _might_ get it right with as little guidance
as draft-ietf-tls-renegotiation-01 currently provides if they've been
following the discussion sleep over their implementation for several
days and test it extensively.  The discussion seems to indicate that
even experienced implementers may get it wrong, and that some
are much more eager to ship than to think about it and test.

And if implementors need an extensions-intolerant server for testing
-- that shouldn't be a problem, you can easily make one yourself;
it is likely a simple 1-2 LoC change to your own code.  ;-)

-Martin

---

From: Michael Gray <[email-masked]>
Date: Fri, 11 Dec 2009 09:46:48 +1000

Paul Hoffman <[email-masked]> wrote:

> itself (no MCSV), while others are advocating MCSV by itself (instead of
RI).
> advocating? It greatly affects the conversation. Thanks!

I strongly prefer: MCSV by itself (instead of RI)

Additionally I prefer draft-mrex-tls-secure-renegotiation-03 over
draft-ietf-tls-renegotiation-01.

- Mick Gray
- IBM

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Robert Relyea <[email-masked]>
Date: Thu, 10 Dec 2009 16:13:37 -0800

> While following the numerous threads, it seems that some people are advocating adding MCSV to RI, while others are advocating RI by itself (no MCSV), while others are advocating MCSV by itself (ins…
I prefer
RI alone, but I'm ok with MCSV with RI.

I'm absolutely against MCSV alone.

bob

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Dec 2009 17:07:13 -0800

On 2009-12-10 16:13 PST, Robert Relyea wrote:
> I prefer RI alone, but I'm ok with MCSV with RI.
> 

Ditto.

Furthermore, I would say that MCSV should be used ONLY by clients that
are willing to speak SSL 3.0 or 3.1 if the server negotiates that.
A client that is only willing to speak SSL 3.2 (TLS 1.1) or later need
not bother with MCSV.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Sat, 12 Dec 2009 19:32:59 +0100

> It greatly affects the conversation. Thanks!

I support the RI, with MCSV added since it appears to be necessary in some  
situations.

I do not support MCSV without RI.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************