This LGTM.
On Fri, Feb 20, 2015 at 8:23 AM, Richard Barnes <r...@ipv.sx> wrote:
>
>
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet <
> 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. 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.
> """
>
>
>
>>
>> I'm going to submit version -10 now.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://andyet.com/
>>
>>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
