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
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
