Those fixes are fine with me. On Fri, Feb 20, 2015 at 11:43 AM, Peter Saint-Andre - &yet <pe...@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 >> <pe...@andyet.net <mailto:pe...@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 mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
