IETF Logo Mail Archive

Re: [TLS] Inclusion of OCB mode in TLS 1.3

Roland Zink <roland@zinks.de> Mon, 26 January 2015 09:43 UTC

Return-Path: <roland@zinks.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405EC1A701E for <tls@ietfa.amsl.com>; Mon, 26 Jan 2015 01:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqfaFf_kffwA for <tls@ietfa.amsl.com>; Mon, 26 Jan 2015 01:43:37 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274921A1B87 for <tls@ietf.org>; Mon, 26 Jan 2015 01:43:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1422265414; l=3093; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From: Date; bh=OV8ozPqozhDTpiyRLbdUGK/oblkAbvLTtnNVzyHYiH4=; b=Eeg5IFJgDm82SlpL8+F/+i/ZiX/kOq70Lgg8OMz1TB1n6oqjfgScZABENJh/MoohTxz unj9nKEQwNnmRGpsRxY4G8fHfywlKR664LRx0AgeAfRMvto2o4GDoEq3WRXpdyy1p2YSM VS58YF6froDIZY/4GFttuDF7f8fm/Aa2FYU=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyJNOICzXh2STKTH/g8cJoUPuG6
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:8f9:68cf:6224:1b5b] ([2001:4dd0:ff67:0:8f9:68cf:6224:1b5b]) by smtp.strato.de (RZmta 37.1 AUTH) with ESMTPSA id L04136r0Q9hY0Sv (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for <tls@ietf.org>; Mon, 26 Jan 2015 10:43:34 +0100 (CET)
Message-ID: <54C60C45.3070407@zinks.de>
Date: Mon, 26 Jan 2015 10:43:33 +0100
From: Roland Zink <roland@zinks.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73AAF64DCA@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF64DCA@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------050804060602050404060408"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1csrznUFYPB8Zq69sgjgdPoajvM>
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 26 Jan 2015 09:43:39 -0000

On 25.01.2015 05:05, Peter Gutmann wrote:
> Aaron Zauner <azet@azet.org> writes:
>
>> That's a nice trick but as you point out pretty useless in terms of a PKI.
> It's done solely to deal with browsers, which demand to see a certificate when
> they're connecting to something via TLS.
>
> (Aside: You can see why some people think the CA/Browser forum as a conspiracy
>   to force the use of certs, despite there being very good alternatives
>   available browsers force you to use certificates whether they're appropriate
>   or not).
You probably need to blame IETF for this, for example RFC2818 (HTTP Over 
TLS) states:


      3.1 <http://tools.ietf.org/html/rfc2818#section-3.1>. Server Identity

In general, HTTP/TLS requests are generated by dereferencing a URI. As a 
consequence, the hostname for the server is known to the client. If the 
hostname is available, the client MUST check it against the server's 
identity as presented in the server's Certificate message, in order to 
prevent man-in-the-middle attacks.

Regards,
Roland

v2.23.0 | Report a Bug | By Email