Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

Richard Barnes <rlb@ipv.sx> Fri, 20 February 2015 17:06 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE81A1B7F for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 09:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 l6uELNFdXVQf for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 09:06:18 -0800 (PST)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE23F1A0187 for <uta@ietf.org>; Fri, 20 Feb 2015 09:06:15 -0800 (PST)
Received: by lbiz11 with SMTP id z11so7525967lbi.5 for <uta@ietf.org>; Fri, 20 Feb 2015 09:06:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+9VH+gnWuPaS8MR7t9ERuk5PLpKnLYw0hOseh3DvNcA=; b=IPyPjsruTNC5ept1C8VS/2aOW0V76PsgXmecmZwKE1uOTOh9jq//x3yNvWFjtbmwsQ wSrL90uWXaReNk69Qj/DfYMYPPcevt9TkIr6T0bWA+HhZsVIP2npZdHcIvRAvpSM311f BD4jlzsWGuJPUIzt4Kanj8gLPneHDJ29D5tEEBnJNPBvClHG7AlEIP6hRw6mEYUwiBFH hp6pgB2kr5TmAOX7X0iMKY0UrawTtah3y7dFsIE3OKnseQ2Z4kWv1sSWzYgRx4KRnw6S ygKaGSdDHfmlZVLUHKhvyc8MTVHG1eHTxSH7EOo/BckT+1/asc/MLY4IXWp9VL1tZY65 XeIw==
X-Gm-Message-State: ALoCoQmshQLGlwWkr7cehWmV4pTe9xH4fUm0PXDpNz5sAi6JByXs/43OT+9S2pvao9ViYvLrD26e
MIME-Version: 1.0
X-Received: by 10.112.126.162 with SMTP id mz2mr9246039lbb.51.1424451973811; Fri, 20 Feb 2015 09:06:13 -0800 (PST)
Received: by 10.25.135.4 with HTTP; Fri, 20 Feb 2015 09:06:13 -0800 (PST)
In-Reply-To: <54E76442.5000704@andyet.net>
References: <20150219033433.10815.25308.idtracker@ietfa.amsl.com> <54E56454.7080307@andyet.net> <CAL02cgS+h2jkOChJkoCy7gHvFQEe22SRRAg5om00ZpiHCOi_2g@mail.gmail.com> <54E5B84C.9040400@cs.tcd.ie> <CAL02cgSem5aW+mhPED3C_5NTfA4YRhr5FSUD3+NnTE_t-8y6Gg@mail.gmail.com> <20150220042718.GR1260@mournblade.imrryr.org> <CA+K9O5QvmBDPhE1GNbnb+OqfWd3C+2Hyp=X2OCJWjpXFK9npNw@mail.gmail.com> <54E747EC.2020905@andyet.net> <CAL02cgR5C_ZQRVGKLCvWh9svqkv6q3DvkvieF7SksywinXeyEQ@mail.gmail.com> <54E76442.5000704@andyet.net>
Date: Fri, 20 Feb 2015 12:06:13 -0500
Message-ID: <CAL02cgTqgO8TgV3KKti9oeDzveWTx=ZgCBcB8HYkBRvgWKJzwA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Content-Type: multipart/alternative; boundary="001a11c373dce6216e050f88111c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/4GZ9QAcYDQs_NQh6XWTwk1dZovw>
Cc: "uta@ietf.org" <uta@ietf.org>, Ralph Holz <ralph.ietf@gmail.com>, The IESG <iesg@ietf.org>
Subject: Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 17:06:22 -0000

Those fixes are fine with me.

On Fri, Feb 20, 2015 at 11:43 AM, Peter Saint-Andre - &yet <peter@andyet.net
> wrote:

> Modulo a few nits (inline), this seems acceptable to me.
>
> On 2/20/15 9:23 AM, Richard Barnes wrote:
>
>>
>>
>> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet
>> <peter@andyet.net <mailto:peter@andyet.net>> wrote:
>>
>>     On 2/20/15 3:45 AM, Ralph Holz wrote:
>>
>>         Hi Viktor,
>>
>>              Basically, I'm fine with "raising the ceiling" as high as
>>         it seems
>>              to make sense, but once the floor is raised too high, the
>>         BCP no
>>              longer applies to opportunistic TLS.
>>
>>
>>         Thanks for jumping in and providing a good summary.
>>
>>         In my opinion, the purposes of this BCP *and* of OS are best
>>         served if
>>         we leave the BCP wording as it is - we address the authenticated
>> use
>>         case only. There are more than enough deployments that are
>>         covered by
>>         the BCP's recommendations. For OS, I would be happy to see a
>>         different
>>         document to focus on that use case, and do it well - as indeed
>>         the WG
>>         consensus was, too.
>>
>>
>>     +1
>>
>>
>> I am also +1 to a separate document for opportunistic.  It's just the
>> "unauthenticated" stuff that I object to, and the fact that the two are
>> confused with each other in 5.2.  We need to disentangle the two to be
>> clear about what we're talking about.
>>
>> It's also important to keep in mind that while opportunistic usage of
>> TLS may imply skipping authentication, the converse is not necessarily
>> true -- there are use cases for unauthenticated TLS that not
>> opportunistic (i.e., they will not fall back to plaintext).
>>
>> With those considerations in mind, I would propose the  following
>> revisions to sections 5.1 and 5.2 (replacing one paragraph in 5.1 and
>> all of 5.2):
>>
>> """
>> 5.1.
>>
>> ...
>>
>>     With regard to authentication, TLS enables authentication of one or
>>     both end-points in the communication.  In the context of opportunistic
>>     security [RFC7435], TLS may be used without authentication.
>>
>
> Instead of "may", I'd prefer "can be" or "is sometimes" or "is often"
> because "may" implies permission (let some other spec say it's acceptable).
>
>  As
>>     discussed in Section 5.2, considerations for opportunistic security
>>     are not in scope for this document.
>>
>> ...
>>
>>
>> 5.2.  Opportunistic Security
>>
>>     There are several important applications in which the use of TLS
>> itself
>>     is optional, i.e. the client decides dynamically ("opportunistically")
>>     whether to use TLS with a particular server or to connect in the
>> clear.
>>     This practice, often called "opportunistic security", is described at
>>     length in [RFC7435].  These scenarios also often involve support for
>>     legacy equipment.
>>
>
> Instead of "equipment", I'd prefer "deployments" because "equipment" makes
> it sound a hardware issue.
>
>      In such cases, some of the recommendations in this document might
>>     be too strict, since adhering to them could cause fallback to
>> plaintext,
>>     a worse outcome than using TLS with an outdated protocol version
>>     or ciphersuite.  The sense of the UTA Working Group was to complete
>>     work on this document about best practices for TLS in general, and to
>>     initiate work on a separate document about opportunistic TLS.
>> """
>>
>
> +1 otherwise.
>
> Peter
>
>
>