Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned

mrex@sap.com (Martin Rex) Tue, 14 April 2015 22:53 UTC

Return-Path: <mrex@sap.com>
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 260F21B303B for <tls@ietfa.amsl.com>; Tue, 14 Apr 2015 15:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 GwyUSX28l_aV for <tls@ietfa.amsl.com>; Tue, 14 Apr 2015 15:53:32 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F321B3038 for <tls@ietf.org>; Tue, 14 Apr 2015 15:53:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EDEA1449F4; Wed, 15 Apr 2015 00:53:28 +0200 (CEST)
X-purgate-ID: 152705::1429052009-000007DF-37C73035/0/0
X-purgate-size: 2717
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9C6DE43DB2; Wed, 15 Apr 2015 00:53:28 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 924711B28A; Wed, 15 Apr 2015 00:53:28 +0200 (CEST)
In-Reply-To: <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com>
To: Hubert Kario <hkario@redhat.com>
Date: Wed, 15 Apr 2015 00:53:28 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150414225328.924711B28A@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GxYTD2yxyNeiRr3lPrMCVR_DqQM>
Cc: tls@ietf.org
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 14 Apr 2015 22:53:35 -0000

Hubert Kario wrote:

> Martin Rex wrote:
>> Andrei Popov wrote:
>>>
>>> Yes, this is an example of NPN legacy in ALPN,
>>> and yes there is some API pain involved.
>> 
>> I'm not trying to break things and I'm not advocating to change
>> any existing APIs.  But I've just been asked for support of this
>> and am looking into newly implementing it, and I would appreciate
>> if we (i.e. the IETF TLS working group) could restrict the TLS ALPN IDs
>> at least by banning the character 0 from TLS ALPN ID registrations now.
>> 
>> Being allowed to reject embedded NULs would facilitate some aspects
>> (save me a few lines of code).
>> 
>> I can live with UTF8.
>> 
>> A single reserved character (such as colon ':' or pipe '|' or comma ',')
>> would allow me to avoid a character escaping scheme for the API I'm
>> trying to create, but I could live with this issue being a proprietary
>> thing.
> 
> You don't prevent CVE-2009-2408-like exploits by banning nulls in fields.

I was talking about *API* stuff, not about wire-level encoding and
TLS protocol stuff.

To be able to support the currently (unreasonably broad) set of
what TLS ALPN IDs may be registered, you would have to create an
API where the caller would have to supply the *input* (from application
to TLS implementation) as an array-of-blobs, i.e. explicit length fields

A concatenated flat-string representation would be *MUCH* simpler
and nicer at the API level.


> 
> If anything, the RFC could be updated to explicitly state that
> implementations MUST be able to handle the case where the IDs
> include null bytes.

That would be insane.

If anything, an implementation receiving a ALPN ID with embedded
NUL characters should drop and ignore that bogus ALPN ID.


> 
> But this is the case for basically all fields both in TLS and X509...

That applies only to fields with unreasonable definitions.

Look at the TLS Server Name Indication extension:

  https://tools.ietf.org/html/rfc6066#section-3

this has a reasonable definition for the "host_name(0)" is limited to
"fully qualified DNS hostname", which means that not just embedded
NULs are prohibited (and can be immediately dropped and ignored by the TLS
ClientHello PDU parser), but also "host_name(0)" > 255 chars and
there are several other constraints on DNS hostnames.


Robust and conservative design means that you check and skip invalid data
as early as possible, to limit the attack surface.  With how TLS ALPN
is currently defined, you can *ALWAYS* target the application on top
of TLS with attacks, because the TLS implementation is not currently
allowed to weed out obvious crap right away. 


-Martin