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

Nikos Mavrogiannopoulos <> Wed, 27 January 2010 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE4D3A6A14; Tue, 26 Jan 2010 23:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u+3fDJrz9a2V; Tue, 26 Jan 2010 23:32:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C09A53A681F; Tue, 26 Jan 2010 23:32:59 -0800 (PST)
Received: by pwi20 with SMTP id 20so3866179pwi.29 for <multiple recipients>; Tue, 26 Jan 2010 23:33:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=2V+4jk6hDOZLseaZIUJvXWfXy7uK04PkIYyoFdqcmss=; b=hDzm/3UFXCbomGv4Zx1qUU1UUuaaHc0WnmkuYeZiGZWylRr/d8tNGy8bmY11QpDnoK dRveC2Aiqftmyfia2BDL29Zx7OPNuQnNaOQk/wbtuVOKhiMzLT9MtHdNGQ7DRuqV+BFB tNjCHZBJckqq961MSx4vg8XnLgjuxrx/Seyek=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XKJ5Dfn1buOTTln2F1iHUoj8KIcrsqAvWLVZSMMmcafEKq645ub0ZRqc21VANrJFiA T78gxeT6rbJ5FmCq6WUZTAqWHqOBGPN3Bv7WPS6UI1LeMxmIhPUJcu6c+wvFxQvzCbCj BI9VwMqKpjUxpud71U8xdmA5bWBPrwU+sSMr0=
MIME-Version: 1.0
Received: by with SMTP id m28mr6313514wag.227.1264577590143; Tue, 26 Jan 2010 23:33:10 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 27 Jan 2010 08:33:10 +0100
X-Google-Sender-Auth: ca7789d66fc3e088
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset=ISO-8859-1
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: Wed, 27 Jan 2010 07:33:00 -0000

On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <> wrote:

>> <aside>That's been the standard for PKIX RFCs for at least ten years
>> (actively acknowledged by WG mmembers), although perhaps its spread
>> to other groups should be discouraged.</aside>
> I fully agree.
> That may be attributed to the fact that a large part of PKIX is dealing
> with policy issues with the objective to prevent/prohibit interoperability.

On the contrary. I believe allowing the sending of both SCSV and extension
might harm interoperability instead. Consider the case of most popular client
implementations are sending both SCSV and extension (it's easier to do so).
A developer of a server might then consider checking only for SCSV (since all
of the popular ones he tested with send both). Thus interoperability with less
popular clients that only send extension stops.

This scenario might not be very likely, but this kind of issues were
not rare in
TLS for quite long :)

best regards,