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

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 20 February 2015 20:41 UTC

Return-Path: <peter@andyet.net>
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 547A91A8792 for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 12:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 JDD1gT32G0mV for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 12:41:49 -0800 (PST)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (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 6BE9B1A8799 for <uta@ietf.org>; Fri, 20 Feb 2015 12:41:49 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id b16so6003814igk.1 for <uta@ietf.org>; Fri, 20 Feb 2015 12:41:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D7eGqTJT5S6zda4+oM4syFqpJeRSMIBMy2Q3iKArw/U=; b=KpZQK2qHuQ6zMlgewVoA6ENolXp3HXnxSEsWkJHukM1Scg0JQpQeDUVYnYPUFIqqI5 YaUkSXKvq62Sv3Ab4rKS0yWpquNUR09ALoJRUN5t21pP/mXwJhxTXTpYzOG0I22oKfCn 8nIe2pRHYCkzi0qk1O4Y49UViGz++FDY1xBDCsxkiR23gYjYpCESOku8EKEjT/McKUoW VE6Xq3T5Il0Pl7KtnNsL1CEEuO+0ziFhZfe+lp8ARZQfxPIST2M8lHll/vYpyjKxbfP0 ZIjypO9Hz0ef5QJe5Px4rDOS5K+WNIq+cgCzf698URbupY5QFad1/IIQi4A8E0lqn781 C9ag==
X-Gm-Message-State: ALoCoQkPhLdh8M6qhL4k3gRmHNFV6+JwJD9oZKRbHstg8BnxPgT3qLXacN/DmU5ZU0QK8Jpbc1Tq
X-Received: by 10.107.40.2 with SMTP id o2mr15850100ioo.68.1424464908845; Fri, 20 Feb 2015 12:41:48 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 130sm12039552ioz.10.2015.02.20.12.41.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 12:41:47 -0800 (PST)
Message-ID: <54E79C0A.1070801@andyet.net>
Date: Fri, 20 Feb 2015 13:41:46 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, Richard Barnes <rlb@ipv.sx>
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> <54E7873A.9060301@cs.tcd.ie> <CAL02cgQ6FuRHt7o2f94jDDEQOFqzh_PCn_VHuFJY1q-sEaDTbg@mail.gmail.com> <54E7976B.7090604@qti.qualcomm.com>
In-Reply-To: <54E7976B.7090604@qti.qualcomm.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/dZkUqlOyAT003IRqm_bXDKYLyu0>
Cc: "uta@ietf.org" <uta@ietf.org>, Ralph Holz <ralph.ietf@gmail.com>, The IESG <iesg@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 20:41:51 -0000

On 2/20/15 1:22 PM, Pete Resnick wrote:
> On 2/20/15 1:43 PM, Richard Barnes wrote:
>>
>> On Fri, Feb 20, 2015 at 2:12 PM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote:
>>
>>
>>>         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.
>>
>>     No, I don't believe we've decided that UTA will be the place where
>>     we develop a BCP on OS. [...]
>>
>>     I'd really really hope we disentangle that discussion from this
>>     draft though, so please replace the last sentence with:
>>
>>                   "The sense of the UTA Working Group was to complete
>>     work on this document about best practices for TLS in general, and to
>>     for work on a separate BCP document about opportunistic security
>>     to be done later."
>>
>>
>>
>> FWIW:
>> - That text is not mine; it has been in since -07.
>> - I would personally be A-OK with UTA working on opportunistic TLS,
>> especially in the sense of providing advice on how to interop with old
>> stuff in ways most likely to result in TLS usage.
>> - It's probably not a great idea to say that in this document
>>
>> How about:
>> "The sense of the UTA Working Group was to complete work on this
>> document about best practices for TLS in general, and to leave
>> recommendations about opportunistic TLS for future work."
>
> Or we could drop mention of the WG entirely:
>
> "This document specifies best practices for TLS in general. A separate
> document with recommendations for the use of TLS with opportunistic
> security is to be completed in the future."

Sure.

So (with some hopefully slight edits)...

###

5.2.  Opportunistic Security

    There are several important scenarios in which the use of TLS 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] and is often motivated by a desire
    for backward compatibility with legacy deployments.

    In these scenarios, some of the recommendations in this document
    might be too strict, since adhering to them could cause fallback to
    cleartext, a worse outcome than using TLS with an outdated protocol
    version or cipher suite.

    This document specifies best practices for TLS in general.  A
    separate document containing recommendations for the use of TLS with
    opportunistic security is to be completed in the future.

###