IETF Logo Mail Archive

Re: [TLS] TLS identity protection using Signaling Cipher Suite Value

Mohamad Badra <mbadra@gmail.com> Fri, 02 December 2011 12:09 UTC

Return-Path: <mbadra@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6321F9928 for <tls@ietfa.amsl.com>; Fri, 2 Dec 2011 04:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2liFNV-2+cSf for <tls@ietfa.amsl.com>; Fri, 2 Dec 2011 04:09:48 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8330721F9924 for <tls@ietf.org>; Fri, 2 Dec 2011 04:09:48 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so2521857vbb.31 for <tls@ietf.org>; Fri, 02 Dec 2011 04:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c+TbY7x2nlSlAeWnaiu4veAg7Zm24McpsXfNLoH/cwI=; b=iuQ/WLkYga7jAuEQZg71dr155dT0HvFHn0w1J++u8w0GtPxRPa5ebcEmb5fVgOU3S2 zcCn0n45s3Q1962wbsA4HIBZoIb9mhlbC5pV4tzfE+VTOowLDguxP1K66/epIsm+Wzzt tB4LnobZBEvikQXCgVSz8PwxjlZX8X0U8md+4=
MIME-Version: 1.0
Received: by 10.52.177.34 with SMTP id cn2mr9458849vdc.34.1322827784722; Fri, 02 Dec 2011 04:09:44 -0800 (PST)
Received: by 10.220.191.13 with HTTP; Fri, 2 Dec 2011 04:09:44 -0800 (PST)
In-Reply-To: <201111302341.pAUNfJDa008028@fs4113.wdf.sap.corp>
References: <CAOhHAXzwDB+9ABL2k5mUEFvXckoFbRCkQfuQyCruqN+MQBRS_g@mail.gmail.com> <201111302341.pAUNfJDa008028@fs4113.wdf.sap.corp>
Date: Fri, 02 Dec 2011 13:09:44 +0100
Message-ID: <CAOhHAXzNZn93R3sMzXNb9qxOUOc_bucwaXfO1BKZ6xuPr_9YCg@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="20cf3071cc903518d804b31ad881"
Cc: tls@ietf.org
Subject: Re: [TLS] TLS identity protection using Signaling Cipher Suite Value
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 02 Dec 2011 12:09:49 -0000

On Wed, Nov 30, 2011 at 12:41 AM, Martin Rex <mrex@sap.com> wrote:

> Badra wrote:
> >
> > Martin Rex <mrex@sap.com> wrote:
> > >
> > > As I previously mentioned, the only reliable protection during the
> > > handshake would be an indication from the server that is authenticated
> > > by the server credential an can *not* be stripped from the handshake.
> > > Basically, it would need to be hardwired into the server's credential,
> > > like an additional certificate extension or a new EKU OID.
> >
> > As you previously mentioned too, hardwiring an new optional TLS protocol
> > feature into a TLS server certificate, resulting in potentially hard to
> > diagnose handshake failures.
>
> This "hard to diagnose handshake failures" refers only to client
> implementations that would check for this server certificate attribute
> and not sensible report to the user why the client implementation
> aborted the handshake.  "old" clients who do not check the feature
> would not abort.  Typical user reaction "but it works with Browser X!".
>
> >
> > If the client doesn't receive such a message from the server, it must
> > stop the TLS handshake
>
> Of course, you could implement it as a client-side credential attribute
> which says "never send in the clear", instead of negotiating the protocol
> feature with the server.  That is not so much different from the server
> conveying the info through a certificate attribute, just that it is
> entirely up to the client whether an when it is being "enforced",
> and the server has no say in that.  If the user tries to use such a
> feature before the server has even implemented it, the user will
> face a failure (and switch it off).  Who is going to reenable it
> when the server adds the feature, then?  If the server could steer
> this with a certificate attribute, this would provide a certain
> level of synchronization and negotiation whether the feature is
> available and can (or should) be used.
>


Shall be the server's indication authenticated? (i.e. the client's
indication is not authenticated)

Best regards
Badra

v2.23.0 | Report a Bug | By Email