Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Marsh Ray <> Tue, 12 January 2010 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D80DA3A6A75 for <>; Tue, 12 Jan 2010 09:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VEjO53HZRfGY for <>; Tue, 12 Jan 2010 09:22:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1614C3A67AA for <>; Tue, 12 Jan 2010 09:22:11 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NUkRU-0002OO-2L; Tue, 12 Jan 2010 17:22:08 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 101DF6076; Tue, 12 Jan 2010 17:22:06 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX18ARlV+L8oNFisAQpX1bsQtIpez2cXsjEM=
Message-ID: <>
Date: Tue, 12 Jan 2010 11:22:06 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "Kemp David P." <>,
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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, 12 Jan 2010 17:22:12 -0000

Martin Rex wrote:
> A TLS client or TLS server that does _not_ interoperate with an old
> TLS implementation on the initial handshake is simply not compliant
> to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is
> negotiated.

I can write an HTTPS server that refuses to talk to clients which do not
send the SNI extension. I can write a client that refuses to talk to a
server that doesn't supply some obscure field in the server cert. Don't
say it's "simply not compliant" to refuse to talk to somebody you decide
not to trust.

> The new specification about (secure) TLS renegotiation _only_
> deprecates an optional feature of the existing protocol and
> adds a new optional feature for them.

That's news to me.

> This spec does _NOT_
> change the core protocol.  Otherwise it would not be an
> update, but a new protocol.

Here's the part about "Updates:". Those look like "core protocol" RFC
numbers to me, but I suppose it's academic.

> Network Working Group                                        E. Rescorla
> Internet-Draft                                                RTFM, Inc.
> Updates:  RFCs 5246, 4366, 4347,                                  M. Ray
> 4346, 2246 (if approved)                                     S. Dispensa
> Intended status:  Standards Track                            PhoneFactor
> Expires:  July 8, 2010                                          N. Oskov
>                                                                Microsoft
>                                                             Jan 04, 2010

Maybe in theory, this is an optional extension, don't implement it if
you don't want it. But you'll probably have to explain to your customers
why you won't fix something their vulnerability scanners are complaining

- Marsh