Re: [TLS] Updated draft

Martin Rex <mrex@sap.com> Fri, 18 December 2009 15:49 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15053A67AE for <tls@core3.amsl.com>; Fri, 18 Dec 2009 07:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level:
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blRoIT97PpvC for <tls@core3.amsl.com>; Fri, 18 Dec 2009 07:49:05 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D70463A672E for <tls@ietf.org>; Fri, 18 Dec 2009 07:49:04 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIFmm4d009495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 16:48:48 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912181548.nBIFmlCk021658@fs4113.wdf.sap.corp>
To: ekr@networkresonance.com
Date: Fri, 18 Dec 2009 16:48:47 +0100
In-Reply-To: <20091218153153.6E1F56C872F@kilo.networkresonance.com> from "Eric Rescorla" at Dec 18, 9 07:31:53 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2009 15:49:06 -0000

Eric Rescorla wrote:
> 
> At Thu, 17 Dec 2009 10:09:11 -0800,
> Michael D'Errico wrote:
> > 
> > s/signalling/signaling/g
> > 
> > In section 4 it says:
> > 
> >     Because the SCSV is equivalent to an empty "renegotiation_info"
> >     extension, any ClientHello used for secure renegotiation MUST include
> >     the "renegotiation_info" extension and not the SCSV.
> > 
> > I would rather see the text say that "an RI extension takes precedence
> > over the SCSV" than to say that you must not send SCSV when you send RI.
> > It is easier for a client to simply include SCSV in every ClientHello.
> > It is also trivial for a server to handle this, as I pointed out in my
> > last message.
> 
> This implements the following point from Pasi's message.
> 
>   - There was some discussion on whether to add the magic cipher suite
>   to patched renegotiation ClientHellos (in addition to the extension),
>   too. I believe rough consensus is not to do this.
> 
> It's of course possible I misunderstood.


I believe that Pasi mainly tried to summarize what he found in
the discussion, and that discussion was huge and pretty fragmented.
A lot of things were discussed with a number of different semantics.

Personllay, I find it difficult to assess consensus on some topics
of the severely fragmented discussions.

I would like to read Pasi's summary as a suggestion to the Working
Group how to resolve the discussed issues, and it is up to the working
group to decide whether the individual items are actually the outcome
with the most support.

Certainly we do not want to re-open each and every issue again.

What Mike and Robert are writing looks like implementers experience
to me, they tried to add the current changes in the spec and are
requesting changes that would make their implementation simpler.

I would appreciate if the spec would be more careful about
MUST NOTs, because we exhibit a tendency to be overly strict
in our specs.  (I had a servere MUST NOT infection in
my first draft, and removing all except those that are actually
required made my document more comprehensible).


-Martin