Re: [TLS] What would make TLS cryptographically better for TLS 1.3

Yoav Nir <> Tue, 05 November 2013 05:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0DA021E80F3 for <>; Mon, 4 Nov 2013 21:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.517
X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lKCrhPjJ3zTI for <>; Mon, 4 Nov 2013 21:53:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E3B621E8063 for <>; Mon, 4 Nov 2013 21:53:03 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id rA55r12j012413; Tue, 5 Nov 2013 07:53:02 +0200
X-CheckPoint: {52788660-0-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 07:53:01 +0200
From: Yoav Nir <>
To: Jeff Jarmoc <>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Date: Tue, 5 Nov 2013 05:53:01 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_DAC7B33BD76F4111AF6FB2218C7294BAcheckpointcom_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-Mailman-Version: 2.1.12
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, 05 Nov 2013 05:53:10 -0000

On Nov 4, 2013, at 6:45 PM, Jeff Jarmoc <<>> wrote:

And what prevents the client from setting the flag despite not checking?

It's the client's responsibility to validate the server's identity (or not) to the extent it chooses to do so.  It's the server's responsibility to validate the client's identity (or not) to the extent it chooses to do so.

Neither end can take on that responsibility for the other.

Right. This is what the NEA people call "the lying endpoint" problem, and it can't be solved without some pretty rubegoldbergian stuff like trusted computing.

I don't want a client on my machine acting as an agent of the server, informing it that my machine is not configured correctly. Sometimes this information leaks (like when my ClientHello has only SSLv3 and TLS_RSA_EXPORT_WITH_RC4_40_MD5. But beyond that, this is none of the server's business.