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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 20 February 2015 19:13 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 3FBE61A039C; Fri, 20 Feb 2015 11:13:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 0cCL3amiKo-l; Fri, 20 Feb 2015 11:13:06 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE631A0358; Fri, 20 Feb 2015 11:13:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4890BBEB5; Fri, 20 Feb 2015 19:13:03 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzc6oXYKlSgr; Fri, 20 Feb 2015 19:13:00 +0000 (GMT)
Received: from [10.10.5.195] (unknown [216.127.117.11]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0D60BDF9; Fri, 20 Feb 2015 19:12:59 +0000 (GMT)
Message-ID: <54E7873A.9060301@cs.tcd.ie>
Date: Fri, 20 Feb 2015 19:12:58 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>, Peter Saint-Andre - &yet <peter@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>
In-Reply-To: <CAL02cgR5C_ZQRVGKLCvWh9svqkv6q3DvkvieF7SksywinXeyEQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/gIi8fO7ucQBcroHUgrnD8tkK7cc>
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 19:13:10 -0000

FWIW, I could live with the current text or with Richard's (modulo
one thing below). Or with stuff in-between.

On 20/02/15 16:23, Richard Barnes wrote:
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet <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. 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.
> 
>    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.

No, I don't believe we've decided that UTA will be the place where
we develop a BCP on OS. Such a document might or might not be all
about TLS, so I think the last sentence needs to not commit the UTA
WG as the venue where such work will be done, as some list discussion
would be needed on that first. (I'm fine that we commit that the
IETF will do that work somewhere, just not with it being definite
that UTA will do it.)

The reason is there are also OS uses of e.g. IPsec on which folks
are working and Adrian and I have an MPLS OS draft. It's not yet
clear whether it'd be best to have a single BCP that has broader
coverage or whether it'd be better to have a TLS specific BCP.

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."

Cheers,
S.

> """
> 
> 
> 
>>
>> I'm going to submit version -10 now.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://andyet.com/
>>
>>
>