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
