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 19:43 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 462971A886B for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 11:43:41 -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=unavailable
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 O_oOQ21IjWXr for <uta@ietfa.amsl.com>; Fri, 20 Feb 2015 11:43:37 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 56C301A1B9A for <uta@ietf.org>; Fri, 20 Feb 2015 11:43:37 -0800 (PST)
Received: by lbiz12 with SMTP id z12so8258901lbi.11 for <uta@ietf.org>; Fri, 20 Feb 2015 11:43:35 -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=f8tNxrz2xYPn4awMyoXUFcvt6jxV6Wd29C00TN75duY=; b=AaqxXe+9YsYhqyTOjZ4SxeFgvT02BsjGY63Sm+n+QqDI0TB3FXk43bmq1+kaMT7fBy HnYAqJUyRsJ0MsVm9GvJCC5nj8ZHB/d+A98u6gB/PDqWXxiN81mYsubpHtKc0fbnYbuP aDgB7nYIQbIbWO7ZhB8qrF/5mmVWh2ymA57S2EQzXrpnbB+f8xbGjKaSFHQ5bRAgEGir Ho2lxaxImDfKpMCKQlgxwj/rGPsryovkChaTFrulcrI66iL1NE71tVcRK2/bHOTajwXI Nr4DTCiF58v7TWqVh0JYxGmcaEntHQlp9VCIC8077ENC1XtDJHs4+PhauDZCKQiubf9q Cejw==
X-Gm-Message-State: ALoCoQksczC+qn8fv7gB0DEYr4PBNGU113vpsxNEapuL7B7hVPZAkGyX5zI5CRhC4zTGzE4sdPWT
MIME-Version: 1.0
X-Received: by 10.112.110.231 with SMTP id id7mr8042003lbb.28.1424461415613; Fri, 20 Feb 2015 11:43:35 -0800 (PST)
Received: by 10.25.135.4 with HTTP; Fri, 20 Feb 2015 11:43:35 -0800 (PST)
In-Reply-To: <54E7873A.9060301@cs.tcd.ie>
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>
Date: Fri, 20 Feb 2015 14:43:35 -0500
Message-ID: <CAL02cgQ6FuRHt7o2f94jDDEQOFqzh_PCn_VHuFJY1q-sEaDTbg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="001a1134daf6ac9c94050f8a447a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/5RbvsK67mkwLr2dm9psrnm9ZuYE>
Cc: "uta@ietf.org" <uta@ietf.org>, Ralph Holz <ralph.ietf@gmail.com>, The IESG <iesg@ietf.org>, Peter Saint-Andre - &yet <peter@andyet.net>
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:43:41 -0000
On Fri, Feb 20, 2015 at 2:12 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > 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. 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." > 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/ > >> > >> > > >
- [Uta] Richard Barnes' Discuss on draft-ietf-uta-t… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Brian Smith
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Brian Smith
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Ralph Holz
- Re: [Uta] Modular vs. modp Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- [Uta] Modular vs. modp (was: Richard Barnes' Disc… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Daniel Kahn Gillmor
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… t.p.
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick