Re: Fwd: Wording for strict vs implicit TLS in <draft-elie-nntp-tls-recommendations-01.txt>

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 23 December 2016 20:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761141294DA for <ietf@ietfa.amsl.com>; Fri, 23 Dec 2016 12:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 lNQWjy8Ipm-C for <ietf@ietfa.amsl.com>; Fri, 23 Dec 2016 12:48:02 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E9412945E for <ietf@ietf.org>; Fri, 23 Dec 2016 12:48:02 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19D97284DEF; Fri, 23 Dec 2016 20:48:01 +0000 (UTC)
Date: Fri, 23 Dec 2016 20:48:01 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Fwd: Wording for strict vs implicit TLS in <draft-elie-nntp-tls-recommendations-01.txt>
Message-ID: <20161223204801.GN13486@mournblade.imrryr.org>
References: <d43e958e-951c-1106-da2d-cb32be3e5b3b@trigofacile.com> <ad470231-fb77-07e0-fba5-9579fde84282@trigofacile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ad470231-fb77-07e0-fba5-9579fde84282@trigofacile.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/T5OrRK7PjaqzLrGQ2JamFEgqbN0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2016 20:48:03 -0000

On Fri, Dec 23, 2016 at 09:24:03PM +0100, Julien ÉLIE wrote:

> FYI, I'll take into account for the revised version of
> draft-elie-nntp-tls-recommendations the comment Viktor gave in the UTA
> mailing-list.
> 
> The terminology for "TLS negotiation immediately upon connection on a
> separate port" is not consistent between RFCs.
>
> * RFC 7525 uses "strict TLS" (and unfortunately does not define the term).
> * RFC 7672 uses "mandatory TLS".
> * draft-ietf-uta-email-deep uses "implicit TLS".
> 
> As I believe "implicit TLS" is the most accurate wording, I'll also use that term
> for draft-elie-nntp-tls-recommendations.

Minor correction.  The term "mandatory TLS" in RFC7672 is not
describing the same thing as "implicit TLS".  Rather it describes
use cases in which TLS is required by policy, typically in the
context of STARTTLS (RFC 7672 is afterall an MTA-to-MTA TLS document).

With mandatory TLS, STATTLS stripping is not effective, because
the client will refuse to proceed in the absence of TLS support.
The same holds with opportunistic DANE TLS clients, when the server
publishes DANE TLSA records.

-- 
	Viktor.