Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

Martin Rex <> Tue, 26 January 2010 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEC913A69CB; Tue, 26 Jan 2010 12:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZmNbDWd5yfhY; Tue, 26 Jan 2010 12:42:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 669B83A6991; Tue, 26 Jan 2010 12:42:58 -0800 (PST)
Received: from by (26) with ESMTP id o0QKh8Gk021481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 21:43:08 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Paul Hoffman)
Date: Tue, 26 Jan 2010 21:43:07 +0100 (MET)
In-Reply-To: <p06240803c784e0bdf7f7@[]> from "Paul Hoffman" at Jan 26, 10 10:15:11 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2010 20:43:00 -0000

Paul Hoffman wrote:
> At 6:57 PM +0100 1/26/10, Martin Rex wrote:
> >The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6!
> are about half of all MUSTs and SHOULDs in modern IETF standards.

what do you want to say with this?

That implementors should ignore at least half of the MUSTs and SHOULDs
in IETF documents, because they don't make any sense, create unnecessary
interop problems or are otherwise harmful -- and should not be in the
document in the first place?

That may apply to IETF documents where you were involved in the process,
but it did not apply to documents where I was involved ... so far.

The engineer in me is unable to just close his eyes on obvious
problems, in particular when there is an easy fix, I'm sorry.

> >Did anyone of you review the new sections in the -03 draft?
> Yes.

The authors should be interested in the inconsistencies you likely
have encountered while reviewing the -03 draft.

Some aspects are likely more apparent to implementors (one of the
reasons for the IETF "we believe in running code" attitude) -- and to those
who are sufficiently familar with code implementing this part of TLS
to think in terms of actual lines of code, code complexity and testing
effort while reviewing the document.

> >I do not think that rushing the document out of the door as-is
> >would be a good idea.  This would set new lows for the level
> >of IETF Proposed Standard.
> This indicates that you need to read more standards-track RFCs, then.

What is your suggestion to improve the situation?

Reading I-Ds during IETF Last Call and providing feedback to the
authors and/or working group might help.  But that requires that
a document is in a resonable shape when it is being Last Called.

draft-ietf-tls-renegotiation-03 is the first version of the
document that is in a shape close to the expectations of 
the IETF for documents targeting Proposed Standard.

There is considerable a considerable of changes in -03 that wasn't
in any prior version of the document, and there are changes to the
semantics (two entirely new MUST NOTs and two unexplained NOT RECOMMEDEDs)
that are _not_ aligned with the WG consensus preceding the -03 document
and they are in conflict with rfc-2119.

Any discussion (let alone consensus) on the changes in the -03 document
was preempted by the IESG approving the document in less than two
days after publication during the holiday season.

I'm not asking for a new change, I'm asking for a _revert_ of a
new change that creates several unnecessary problems.

And I'm asking for an editorial review of the -03 draft, since
some would seriously benefit from editorial corrections.

The IETF used to be a standardization body with an open and fair
process where technical merit, running code, technical objections
and rough consensus of those who cared was more important
than any count of votes.

I don't want to hold up the document.

I did _not_ complain about the premature IETF Last Call because
I was still hoping the document quality issues could be resolved
entirly during WG discussion (there were ~5 complaints).

I _urged_ Pasi to make his consensus call on SCSV semantics on
Dec 16th, when there was still plenty of time considering the
(lack of) document quality at that point.

In order to help on fixing the problems -03, I even provided
an updated document as suggestion for all the issues that
should be fixed before publication.

After all, the target audience of this document is supposed to
be much larger (within a very short time frame) than most other
documents published by the IETF.  Therefore the technical quality
appears to be significant, in spite of the importance of getting
the solution implemented.