Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

Matt DeMoss <> Thu, 10 February 2011 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D770A3A681A; Wed, 9 Feb 2011 19:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4FIqncw6V2zk; Wed, 9 Feb 2011 19:35:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8B2FB3A680C; Wed, 9 Feb 2011 19:35:48 -0800 (PST)
Received: by fxm9 with SMTP id 9so1023294fxm.31 for <multiple recipients>; Wed, 09 Feb 2011 19:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MlAPwYKSyklW3vhixBNic+syWZ2m22ql6WBme7VJxsM=; b=NvMQQvqvS8ZOiMxZnarlkFH1D74k01sD6vPZBpeRBGJDXaWIbw3PQ8VJU1TABt+OWf hnIX1oUgeCzocgV/O0vLDxSNrTDnk0mE9cCDEU80WVq4OvSipPW8LyhMQ36BqgDdGfmg c5FXR6eg6pmnZaMsdmoHiRMgTz0A50SYjGY1k=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kAtJYV9VPJyV2PP2hgEvqmd2t48YfybqXytevqu8xMz5v7OIApGClSGW3wW3ajYmR0 gvT852xckqv++IaiTlTJx7qLVPZRVsq/f+Wx6fYkzaRFtxNEme43FhJK5whqmfZZL/4R 9ma5Kk1r1jnPkKqQ96aqIybyBKaA335oogLVY=
MIME-Version: 1.0
Received: by with SMTP id v11mr7347101fam.132.1297308959118; Wed, 09 Feb 2011 19:35:59 -0800 (PST)
Received: by with HTTP; Wed, 9 Feb 2011 19:35:59 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 09 Feb 2011 22:35:59 -0500
Message-ID: <>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
From: Matt DeMoss <>
To: Chris Newman <>
Content-Type: multipart/alternative; boundary="20cf3054a541ac1662049be54709"
X-Mailman-Approved-At: Fri, 11 Feb 2011 03:00:39 -0800
Cc:, tsvwg <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Feb 2011 03:35:50 -0000

> I can not deny that separate-port for SSL is simpler to implement on the
> server side (having done both). Since the odds of security bugs increases
> with the amount of code, I must conclude that separate-port SSL is more
> secure for _implementers_ and _implementations_ for that reason alone.

> As an aside, there is no interoperable specification for use of TLS client
> certificate authentication with the "pops" protocol (does it start in
> not-authenticated state and require an AUTH EXTERNAL, or does it start in
> authenticated state -- no way to distinguish the two cases). However, use of
> TLS client certificate authentication with POP+STLS according to written
> rules in RFC 2595 does interoperate.
I think the argument for protecting complex code paths from exposure is much
stronger in the case of required client certificate authentication where
unauthorized users may be able to exercise fewer paths.

There are also some cases where it seems like you get client-cert-auth 'for
free' as a side effect of sitting on top of a TLS implementation that
supports client auth. MS Outlook seems to like this with LDAPS: I doubt it
was a conscious choice on their part to include that mode of authentication.

The separate port model also makes it easier to terminate the TLS tunnel at
a simple load balancing or TLS accelerating device that knows nothing of the
underlying protocol.