Subject: [TLS] Two drafts, two last calls ?

From: Yang Tse <[email-masked]>
Date: Thu, 10 Dec 2009 21:20:35 +0100

Hello,

Given the fact that draft-mrex-tls-secure-renegotiation has already
completed a two weeks period as an Internet-Draft, I would like to
know if the IETF Security Area Director will make a Last Call on this
draft, or if there are any reasons that prevents this from happening.

Cheers,
-- 
-=[Yang]=-

---

From: <[email-masked]>
Date: Fri, 11 Dec 2009 18:07:23 +0100

(wearing Area Director hat)

Let me try to explain the IETF process here:

This is not a competition between two drafts.  The TLS WG has decided
to work on a solution to this problem, and we already know that the
document that will be standardized will have file name
"draft-ietf-tls-renegotiation".

However, it's clear from the IETF Last Call comments that it won't be
version -01 as-is, but there will be at least version -02 (and perhaps
more) with some changes. So the question at hand is what changes
should be included in draft-ietf-tls-renegotiation-02 (or 03/04/...).

A number of people have proposed various changes in the emails during
the past couple of weeks. Martin has decided to write his proposed
changes in the form of an Internet-Draft -- which is sometimes a
better way to communicate such a proposal than just email (and this
is not an uncommon way to communicate in IETF).

Which changes get included in the final document depends on IETF
community consensus, as judged by the IESG (and not, for example, 
the editors/authors of the document).

Although the IETF occasionally standardizes two different solutions to
the same problem, this is not common. Also, during the IETF Last Call,
I have not seen any indiciation from the community that they would
like to see two very similar solutions standardized.

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Yang Tse
> Sent: 10 December, 2009 22:21
> To: [email-masked]
> Subject: [TLS] Two drafts, two last calls ?
> 
> Hello,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yang Tse <[email-masked]>
Date: Fri, 11 Dec 2009 19:14:50 +0100

Pasi,

Thanks for the IETF process explanation.

Just wanted to be sure that draft-mrex-tls-secure-renegotiation
contents would at some point be formally evaluated by IESG and would
not simply become an I-D sitting on a shelve with no formal review.

Cheers,
-- 
-=[Yang]=-

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2009 12:10:57 -0800

That's not what he said. He said:

>. . .

If the IETF community consensus is to not include the features of draft-mrex-tls-secure-renegotiation into draft-ietf-tls-renegotiation, then those features will probably not be evaluated by the IESG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 21:25:01 +0100 (MET)

> not simply become an I-D sitting on a shelve with no formal review.

The submission of a document/proposal as an internet-draft itself
is _not_ a request for review by the IESG.

Chris Newman asked me to write up and submit my proposal as a draft,
and Joe Salowey asked the WG in a consensus call for a specific
proposal that people would support, so I wrote that document.

What I do _not_ want is two solutions for this problem, that would
be incompatible with my objectives.

There were several motivations for me to do this:

(1) the KISS principle http://en.wikipedia.org/wiki/KISS_principle
(2) usable for all protocol versions of TLS plus SSLv3
(3) can easily and safely be used for backwards interoperability scenarios
(4) enable non-disruptive updates of the installed base

(1) if you look at http://en.wikipedia.org/wiki/KISS_principle
    you find the following:

      The principle is best exemplified by the story of Johnson handing a
      team of design engineers a handful of tools, with the challenge
      that the jet aircraft they were designing must be repairable by
      an average mechanic in the field under combat conditions with
      only these tools.

    This compares well to the maintenance people that will be tasked to
    retrofit secure renegotiation (or the RI-Minimal renegotiation-less
    version thereof) into old lines of code that they know marginally
    at best, plus the targets: fast patch development, quick and broad
    deployment into an installed base of largely unknown usage scenarios.

    Most of the maintenance guys do NOT have TLS extensions code, so in
    spite of their availability to engineers of new products,
    TLS extensions is something that is definitely not available in the
    toolchest of the average mechanic out in the field!

(2) I found it completely unacceptable that the original proposal
    completely ignored the protocol version { 0x03, 0x00 } in spite
    of knowing that a _even_ a non-negligible amount of the HTTP
    traffic on the internet uses this protocol version--in intranets
    the usage of protocol { 0x03 0x00 } is probably even higher.

(3) Since there will be a non-zero transition period where interop
    with old TLS peers is an absolute requirement for many implementations,
    a reliable protection from downgrade attacks is necessary.

(4) Since the is are still old SSL and TLS implementations in current use
    with limited forward interoperability, hotfixing a feature into
    the installed base that has a proven track record of allergic
    reaction is a bad idea.

    Compare it to swine flu vaccine.  If you had the choice between
    two vaccines, one with a 1% risk of anaphylactic shock and one with
    only 0,01% risk which one would you want to get treated with?

    And if you were a medical doctor in the US and had both of these
    available, which one would you give your high-profile customers?