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 > > >
- [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