Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

From: [email-masked]
Date: Mon, 15 Apr 2019 10:48:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 WG of the IETF.

        Title           : Remote Procedure Call Encryption By Default
        Authors         : Trond Myklebust
                          Charles Lever
	Filename        : draft-ietf-nfsv4-rpc-tls-01.txt
	Pages           : 17
	Date            : 2019-04-15

Abstract:
   This document describes a mechanism that opportunistically enables
   encryption of in-transit Remote Procedure Call (RPC) transactions
   with minimal administrative overhead and full interoperation with ONC
   RPC implementations that do not support this mechanism.  This
   document updates RFC 5531.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-01
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Chuck Lever <[email-masked]>
Date: Mon, 15 Apr 2019 18:14:34 -0400

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
> Date: April 15, 2019 at 1:48:18 PM EDT
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> 

Does this document need to say anything specific about reverse-direction
RPC operations? (i.e., NFSv4.1 callbacks on the same communication channel)

--
Chuck Lever

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 16 Apr 2019 08:37:54 -0400

> RPC operations? (i.e., NFSv4.1 callbacks on the same communication channel)

We might perhaps note that if the server uses a TLS protected channel
to send back channel RPC calls, then those calls are automatically
authenticated by virtue of the server certificate used to set up TLS.
i.e. the client may just want to accept all back channel RPC calls,
including those using AUTH_NULL or AUTH_SYS authentication.

There is the question of the NFSv4 back channel, which is server
initiated. If we want servers to be able to use that as a replacement
for RPCSEC_GSS, then we'd need to specify a certificate for the client
to present to the server. Ditto for NLM, if we want to go even further
back in time...
Do we care?

A more general question that this raises is: Do we consider TLS as
part of the authentication mechanism, and if so, what is its role?
IOW: if the client does present a certificate when it sets up the TLS
channel, then should that suffice to prevent an attacker from setting
up a new TCP connection to the same server, and spoofing the identity
of that client without possessing the original client certificate?
If we do want that ability, then we should also look at consequences
for the NFSv4 state model and perhaps add a SP4_TLS mode to the state
protection negotiation in EXCHANGE_ID (as we already do for SSV).

There is also the issue of trunking. Do we want to allow NFS clients
to use TLS authentication as a way to identify multi-homed servers?

Cheers
  Trond

---

From: David Noveck <[email-masked]>
Date: Tue, 16 Apr 2019 09:39:38 -0400

> RPC operations?

I don't think it needs to, but there are certainly los of reasons we would
want it
to.   The issue that needs to be resolved is that this is a document that
is not
specfic to NFSv4, but is RPC-generic.   If we don't want to change that
right now,
and it would be disruptive, we made need another document about
NFv4-specific
considerations about use of rpc-tls.

> (i.e.,

In this document, it would have to be "e.g."

> NFSv4.1 callbacks on the same communication channel)

In this document, I'm not sure it is worth bothering with.

> including those using AUTH_NULL or AUTH_SYS authentication.

I don't think this, although true, fits in the current document.

I think it would make sense in an NFSv4-focused document

> to present to the server.

Right now, the server can use AUTH_SYS, as well as RPCSEC_GSS.

In this case, the client would be, from the RPC point of view, the server.
It is not clear to me, how the existing text would apply to this situation,
but if it didm't, I don't see trying to tackle that issu in an rpc-generic
document.

> Ditto for NLM, if we want to go even further
> back in time..

I'd prefer not to do that.   I'm not sure exactly how to write an
appropriate
Security Considerations section for a protocol with non-existent security.

> Do we care?

I don't but some people might.

> part of the authentication mechanism,

GIven what the document says about the need/desirability to authenticate
the client, it appears that we do.

> and if so, what is its role?

So far, the role is basically being sure that one doesn't acccept
attacker-generated
(pseudo)-authentications when use of AUTH_SYS is allowed.

> of that client without possessing the original client certificate?

Yes, but that would require the server to decide not to accept
non-TLS-protected
connections.   In the current spec, it appears that that is allowed, but I
think
a full treatment of the issue would require a v4-focused document.

> for the NFSv4 state model

Yes.

> and perhaps add a SP4_TLS mode to the state
> protection negotiation in EXCHANGE_ID (as we already do for SSV)

I think that, given the NFSv4 extension model, that would eequire an
EXCHANGE_ID_PLUSPLUS

> to use TLS authentication as a way to identify multi-homed servers?

Yes we want to but if we want to say that explcitly, we need to wait for
a NFSv4-specfic document.   draft-ietf-nfsv4-rfc5661-msns-uodate-00
will be out soon and I think we could wordsmith something that would
allow this to be done, but being more specfic would delay v41.1 trunking
until rpc-tls had fully matured, which I don' think we want to do.

On Tue, Apr 16, 2019 at 8:38 AM Trond Myklebust <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: David Noveck <[email-masked]>
Date: Tue, 16 Apr 2019 13:09:43 -0400

I'm confused by the addition of the word "opportunistically" in the
abstract.   This document defines an important way of providing security to
RPC-based protocols such as NFSv4, so as to deal with the very real
security problemms that these protocols have.    While these facilities can
only be used when both client and the server provides support, I don't
think that fact alone make the use of these facilties "opportunistic".
What exactlty is this word intended to imply?

---

From: Chuck Lever <[email-masked]>
Date: Tue, 16 Apr 2019 13:11:54 -0400

> On Apr 16, 2019, at 1:09 PM, David Noveck <[email-masked]> wrote:
> 
> I'm confused by the addition of the word "opportunistically" in the abstract.   This document defines an important way of providing security to RPC-based protocols such as NFSv4, so as to deal with the very real security problemms that these protocols have.    While these facilities can only be used when both client and the server provides support, I don't think that fact alone make the use of these facilties "opportunistic".    What exactlty is this word intended to imply?

"Opportunistic" is a term of art. See:

https://en.wikipedia.org/wiki/Opportunistic_TLS

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 16 Apr 2019 13:23:34 -0400

OK, but use of the adverb "opportunistically" without TLS being mentioned
does add confusion.  How about:

This document describes a mechanism that, through the use of
opportunistic TLS, enables
encryption of in-transit Remote Procedure Call (RPC) transactions.
This is done with
minimal administrative overhead and full interoperation with ONC RPC
implementations that do not support this mechanism.  This document
updates RFC 5531.

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Wed, 17 Apr 2019 22:37:04 +0200 (CEST)

----- Original Message -----
> From: "Trond Myklebust" <[email-masked]>
> To: "Chuck Lever" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Tuesday, April 16, 2019 2:37:54 PM
> Subject: Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

>> RPC operations? (i.e., NFSv4.1 callbacks on the same communication channel)

I don't think so. You just describe RPC related behavior. All NFS4 protocol
specific recommendation probably should go into to a different document.

> There is the question of the NFSv4 back channel, which is server initiated.

The same here, a different document that talks about what NFS client should do,
what server should do, implication on pNFS (same security..), migration and so on.

> If we want servers to be able to use that as a replacement

The same way as rfc1831 enforces unix security - up to service specific doc.
Even RPCSEC_GSS doesn't require gss context per user. TLS session per user
might be a challenging task.  

> to use TLS authentication as a way to identify multi-homed servers?

This is an interesting one. What about migration? Require 'Subject
Alternative Name'?  Is this different from kerberos based trunking?

Regards,
   Tigran.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 17 Apr 2019 17:34:29 -0400

> might be a challenging task.

Agreed, but I wasn't considering per user certificates. In the above
discussion I'm only talking about the client identifying itself, and
what consequences that may have.

In essence, the argument boils down to: I think we might be able to
use TLS as a substitute for SSV if the clients identify themselves via
a (per client) certificate.

Dave suggested that might require a new version of the EXCHANGE_ID op,
but I'm less sure. It seems to me that extending the type 'enum
state_protect_how4' by adding a value for SP4_TLS should allow us to
extend the existing EXCHANGE_ID type. Legacy servers would presumably
respond with a NFS4ERR_INVAL  or possibly NFS4ERR_BADXDR, since they
won't recognise that value for the state_protect4_a union, allowing
the client to negotiate down to a supported type.

> Alternative Name'?  Is this different from kerberos based trunking?

You presumably do not want to look exclusively at the alternative
names, since that would imply that the servers are presenting
different certificates, and identify as different services. I agree
though that you might be able to do the same with RPCSEC_GSS.

Cheers
  Trond

---

From: David Noveck <[email-masked]>
Date: Thu, 18 Apr 2019 11:31:52 -0400

> but I'm less sure.

I checked RFC8178 and this can be done without a new op, as long as you are
speaking NFSv4.2.   This would require you recognize all the new ops
in   RFCs
7861/2 to be recognized/decoded although supporting them is not required.

> Legacy servers would presumably

RFC8178 allows RPC-level XDR errors to be returned in this case, although I
don't know if any servers that do that still exist.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 18 Apr 2019 19:15:08 -0400

> On Apr 16, 2019, at 9:39 AM, David Noveck <[email-masked]> wrote:
> 
> I don't think it needs to, but there are certainly los of reasons we would want it
> to.   The issue that needs to be resolved is that this is a document that is not 
> specfic to NFSv4, but is RPC-generic.   If we don't want to change that right now,
> and it would be disruptive, we made need another document about NFv4-specific

Well, let's set aside the parenthetical for a moment.

At one point, Tigran said this:

> But what sould be part of your document is the handling of TLS session
> termination. Something like (please make it rfc language compliant):
> 
> 
>   Client can terminate the TLS session after sending a TLS closure alert.
>   After TLS session termination any other RPC requests over the same connection
>   will fail with AUTH_ERROR.

I think what is intended is that all traffic on that connection,
after the TLS session is established, should be encapsulated and
protected, until the TLS session is terminated.

What I'm wondering is whether it needs to be made explicit that
this would include reverse direction operations. Unlike GSS,
which provides per-request encapsulation, meaning that each
request can use its own security flavor.

TLS is transport-level. We might want to stipulate that operations
in both directions MUST be sent using the negotiated TLS session.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sun, 21 Apr 2019 07:47:31 -0400

> request can use its own security flavor.

I think it would be helpful if it did make that explicit.  Given that
this is a RPC-generic document, v4.1, the only current user of
reverse direction RPC, would need to referenced, informatively,
as an example.

> in both directions MUST be sent using the negotiated TLS session

I don;t think you can do that.   In the case of trunking, there will be
multiple connections and multiple sessions.   Anything related to
trunking would need to be in an v4-focused document.

Another thing that would need to be in a v4-focused document iS
material related to v4.0 callbacks  in which there would potentially
be multiple connections and thus multiple TLS sessions.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 22 Apr 2019 09:58:45 -0400

> On Apr 21, 2019, at 7:47 AM, David Noveck <[email-masked]> wrote:
> 
> On Thu, Apr 18, 2019 at 7:15 PM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Apr 16, 2019, at 9:39 AM, David Noveck <[email-masked] <mailto:[email-masked]>> wrote:
> > 

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Mon, 22 Apr 2019 09:59:18 -0400

> trunking would need to be in an v4-focused document.

I meant "operations in both directions on the same transport connection".

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 Apr 2019 10:48:15 -0500

> https://en.wikipedia.org/wiki/Opportunistic_TLS

RFC 7435 is also a good reference for this topic (and one that has IETF
consensus, FWIW).

The summary of the reasoning for the use of this term is basically that it
does not provide protection in the face of an *active* attacker (that can
force downgrade to the previous/insecure technology), but does protect
against passive observation.

-Ben

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 23 Apr 2019 10:44:03 +0200 (CEST)

The other aspect that probably makes sense to describe is the behavior
when server insist on TLS, some thing like that only operation NULL
is accepted and anything else fails with error AUTH_TOOWEAK or similar.
In general, the point is not to enforce one or an other way, but clearly
specify the client/server interaction to avoid ambiguity for implementors.
IOW, pure egoism :)

Tigran.

----- Original Message -----
> From: "Benjamin Kaduk" <[email-masked]>
> Sent: Monday, April 22, 2019 5:48:15 PM
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

>> > I'm confused by the addition of the word "opportunistically" in the abstract.
>> > This document defines an important way of providing security to RPC-based
>> > protocols such as NFSv4, so as to deal with the very real security problemms
>> > that these protocols have.    While these facilities can only be used when both
>> > client and the server provides support, I don't think that fact alone make the
>> > use of these facilties "opportunistic".    What exactlty is this word intended
>> > to imply?
>>

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 23 Apr 2019 09:42:13 -0400

> specify the client/server interaction to avoid ambiguity for implementors.

Isn't this already taken care of by the NFS layer. Say my server is
exporting only krb5 flavors and my client mounts with sec=sys, I will
get a ERR_WRONGSEC back and mount would fail.

---

From: David Noveck <[email-masked]>
Date: Tue, 23 Apr 2019 10:46:15 -0400

Yes the mount will fail as you describe, but, in that case, the error would
be first detected when you try to access the krb5-only fs.   In the case
Tigran
is mentioning,  the server is interested in preventing unencrypted access
from
the beginning.

This can be an issue in liight of the fact that there is no way (without
rpc-tls)
to cause such operations as EXCHANGE_ID and CREATE_SESSION to be
done with privacy protection.   Also, if the server supports AUTH_SYS at
all,
I think it has to accept it for these operations (again no privacy).  The
problem
that this  leads to is that the clientid and sessionid are the kind of
protocol artifacts that RFC7258 warns us against making observable.   In
the
case of NFSv4.1 they can be the basis of denial of service attacks in that
once the COMPOUND is accepted (easy if AUTH_SYS is supported by
the server at all; not much more difficult in the RPCSEC GSS case since only
a single user needs to be compromised), spurious COMPOUNDs can be
issued so that a legitamate client will have its requests rejected since
they apear
to have invalid slot sequence values :-(.
requests

On Tue, Apr 23, 2019 at 9:42 AM Olga Kornievskaia <[email-masked]> wrote:

> abstract.

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 23 Apr 2019 20:38:48 +0200 (CEST)

----- Original Message -----
> From: "Dave Noveck" <[email-masked]>
> To: "Olga Kornievskaia" <[email-masked]>
> Cc: "Tigran Mkrtchyan" <[email-masked]>, "NFSv4" <[email-masked]>
> Sent: Tuesday, April 23, 2019 4:46:15 PM

> is mentioning,  the server is interested in preventing unencrypted access

Exactly, with sys=krb5x you still allow other securities as long as server
have no idea which export do you want to access. I suggest to document specify
server/client interaction where server allows only NULL and STARTTLS over a
plain connection.

Tigran.

---

From: Chuck Lever <[email-masked]>
Date: Wed, 24 Apr 2019 09:51:25 -0400

> On Apr 22, 2019, at 11:48 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

Indeed, this looks directly on point.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Wed, 24 Apr 2019 10:48:18 -0400

> Indeed, this looks directly on point.

It does but having read this document and considering Ben's statement
that "it :does not provide protection in the face of an 'active' attacker,
I'm
wondering if the 'opportunistic" nature of this approach should be mentioned
quite as prominently as it is in -01.

For example, Tigran is basically asking for a description of how this
mechanism
would be used non-opprtunistically and it seems clear to me that eventually
there will be a need such deployments.   If and when this mechanism is
widely
deployed the failure to establish an encrypted connection is more likely to
be
due to an active attacker rather than a non-rpc-tls-supporting server.

It is not clear to me why, in that event the client should behave passively
in the
face of an active attack.   As i understand it, an eventual Security
Consideraations
is going to have to consider all possible attacks and we want to avoid a
situation
in which an accurate Security Consideration would need to say, in essence,
"omigod,
it's hopeless". :-(

---

From: Chuck Lever <[email-masked]>
Date: Wed, 24 Apr 2019 10:55:50 -0400

> On Apr 24, 2019, at 10:48 AM, David Noveck <[email-masked]> wrote:
> 
> that "it :does not provide protection in the face of an 'active' attacker, I'm
> For example, Tigran is basically asking for a description of how this mechanism
> there will be a need such deployments.   If and when this mechanism is widely
> deployed the failure to establish an encrypted connection is more likely to be
> It is not clear to me why, in that event the client should behave passively in the 
> face of an active attack.   As i understand it, an eventual Security Consideraations
> is going to have to consider all possible attacks and we want to avoid a situation
> in which an accurate Security Consideration would need to say, in essence, "omigod,  
> it's hopeless". :-(

The opportunistic approach is meant to be a step up, not
a full solution. We are bridging a gap here, and I think
we all expect/hope to have deeper solutions in the future.

For instance, we could define an RPC on QUIC transport
type that requires host authentication and encryption from
the get-go.

The current rpc-tls document now RECOMMENDS that an RPC
client's security policy insists on the use of TLS (ie,
that they will immediately close a connection to a server
that does not support TLS). That is a reasonable way to
address active attackers while there is still a large fleet
of RPC implementations without TLS support.

We could also strongly RECOMMEND the use of authentication.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Wed, 24 Apr 2019 15:41:01 -0400

> a full solution.

OK, but the question at hand is whether rpc-tls (or the RFC that results
from it) is to be limited to the opportunistic approach.   I'm arguing that
it should not, and much of what you say below seems to indicate
that you agree.

However, other things you say lead me to a contrary conclusion, so it
would be best if we got a clear answer on this point.

> We are bridging a gap here, and I think

To get those, I think we need do more than expect/hope for them.   I think
we need to plan for them.   One way to do that is to allow rpc-tls to be
used either opprtunistically or non-oportunistically. rather than
restructing it to opprtuunistic use and expect something else to
provide support for the non-opportunistic case.

> type that requires host authentication and encryption from

I've heard some rumblings about QUIC and would like to see an RPC
transport type defined.   However, we haven't yet seen even a
fragmentary individual submission on this topic.   Yes, we could
do this in the future, but it is unwise to count on it any time soon/

> that does not support TLS).

If it does, then it is not opportunistic and there is a conflict with
the abstract which says "opportunistically".

I've been unable to see where it says that.  I've searched the document
for "RECOMMEND".  Also:

It does  say the following which seems to contradict it:

The mechanism described in this document interoperates fully with RPC
implementations that do not support TLS.  The use of TLS is
automatically disabled in these cases.

Tigran is looking for a discussion of this case and can't find it, so, in
any case, it is not just me who isn't able to see this.

> That is a reasonable way to

I don't see that you can RECOMMEND that unconditionally,
especially in an RPC-generic document.   When there are
a large set   of RPC implementations without TLS support,
is precisely when the alternative (i.e. opportunistic) approach
has its greatest value.

> We could also strongly RECOMMEND the use of authentication.

I don't think we should do that in the context of an RPC-generic
document.  Each protocol might reasonbly have its own needs and
policies.

The decision to proceed with an rpc-generic document was intended to
accellerate development of rpc-tls.  That's worked so far but I think that
to
maintain progress we have to avoid the temptation to put protocol-
specific material (most likely for NFSv4) into what should be an rpc-
generic document.   That would essentially undo the decision to make
this an rpc-generic document.

I've thought about something like this for v4-oriented document but
I think that there the need/requirement for authentication of the client
is best tied to use of AUTH_SYS.    If you are using RPCSEC GSS and
have an encrypted channel, you would have adequate NFSv4 security, even
in an internet environment. :-). At that point, client authentication, which
might be work to add to the work already done to implement RPCSEC GSS,
is better seen as OPTIONAL.

---

From: Chuck Lever <[email-masked]>
Date: Wed, 24 Apr 2019 16:48:21 -0400

> On Apr 24, 2019, at 3:41 PM, David Noveck <[email-masked]> wrote:
> 

I don't believe I'm counting on anything, just using
QUIC as an illustration that we are trying to look
ahead.

> I've been unable to see where it says that.  I've searched the document  for "RECOMMEND".  Also:
> 
> The mechanism described in this document interoperates fully with RPC implementations that do not support TLS.  The use of TLS is
> Tigran is looking for a discussion of this case and can't find it, so, in any case, it is not just me who isn't able to see this.

Sorry, I'm talking about the current Editor's Copy
of this document, which is here:

https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html

XML is available here:

https://github.com/chucklever/i-d-rpc-tls/tree/master

> is precisely when the alternative (i.e. opportunistic) approach

I want to have an opportunistic approach for today that
does not get in the way of something we might define later
that has stronger semantics. To me that looks also like
what you are driving at?

> document.  Each protocol might reasonbly have its own needs and

I should have been more clear. I meant "strongly RECOMMEND
the use of a policy that enforces the use of mutual peer
authentication." That is the strongest security we can get
from the mechanisms available within the form of TLS we are
working with here. It feels appropriate to state in an
RPC-generic document, and it does not seem contrary to the
stated goals of opportunistic security as defined in RFC 7435.

See the text in the Security Considerations section, where
the RECOMMENDATION is stated. I'm open to suggestions.

> accellerate development of rpc-tls.  That's worked so far but I think that to 

Trond is also thinking about an NFSv4-specific document that
could help fill in some of the gray areas and flesh out the
side-discussions that have arisen in this thread.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Thu, 25 Apr 2019 08:57:22 +0200 (CEST)

----- Original Message -----
> Sent: Wednesday, April 24, 2019 9:41:01 PM

> any case, it is not just me who isn't able to see this.

I think Chuck's proposal is not contradicting to what I am saying. In "opportunistic"
TLS model it's up to client to close the connection to a server that does not
support TLS and it up to server to reject RPC requests from the clients that
don't start conversation with STARTTLS. Such situation is well defined in rfc3207 (SMTP):

...
   After the client gives the STARTTLS command, the server responds with
   one of the following reply codes:

   220 Ready to start TLS
   501 Syntax error (no parameters allowed)
   454 TLS not available due to temporary reason

   If the client receives the 454 response, the client must decide
   whether or not to continue the SMTP session. Such a decision is
   based on local policy.
...

and

...

   A SMTP server that is not publicly referenced may choose to require
   that the client perform a TLS negotiation before accepting any
   commands.  In this case, the server SHOULD return the reply code:

   530 Must issue a STARTTLS command first
...

Again, I am not pushing for one or an other solution, but for a document
with a monosemantic description.

Tigran.

---

From: David Noveck <[email-masked]>
Date: Thu, 25 Apr 2019 04:46:09 -0400

> I think Chuck's proposal is not contradicting to what I am saying.

I don't know.  I think I'm pretty clear about what you are saying but I'm
less clear about exactly what Chuck is proposing.

Part of the problem is that there are multiple possible "current" documents
being discussed, making the issue of proposed changes to those murky at
best.

> In "opportunistic"

The text you cite is clear enough and I feel rpc-tls would do well to
emulate it, although
it need not make the same decisions.

Unfortunately, if you look at the current document as most people people
would understand
it, i.e. at rpc-tls-01, we see the following problems:

   - There is no discussion of rejection cases, such as rfc3207 provides.
   Instead, the handwavy adverb "automatically" is used.
   - There is no explanation of the opportunistic model leading to
   uncertainty.   Although I have no problem with the way this is done in
   SMTP, I would have a problem with "opportunistic security" as described in
   RFC7435.   If, as Ben indicates, this is a model that is not safe againt
   active attacks, I really don't think we want to go there.

I suggest that we get back to a single current document by Chuck submitting
some reasonably current version.   Then, once that is done, we can discuss
and address the issues of providing a description analogous to the one in
rfc3207 and clarifying use of the term "opportunistic".

By the way, although I don't dispute Chuck's description of this as a "term
of art", the range of descriptions I've seen suggests to me that the most
appropriate artist to cite is Luigi Pirandello, the author of *Così è (se
vi pare) * :-)

On Thu, Apr 25, 2019 at 2:57 AM Mkrtchyan, Tigran <[email-masked]>
wrote:

> >> > >> does not provide protection in the face of an *active* attacker
> (that
> >> can
> >> > deployed the failure to establish an encrypted connection is more
> likely
> >> to be
> >> > > does not provide protection in the face of an *active* attacker
> (that
> >> can