Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 1 Apr 2019 12:06:10 -0400

Comments about the draft-1 and section 4.3 Authentication.

1. Why is there no option of no client authentication and simply using
server-side authentication and using AUTH_SYS on top of it (and
perhaps this is addressed by the 2nd editorial comment in the [] but
the lack including this as an option bothered me). I think this is the
most useful option to be considered. I don't see how adding
self-signed client certificates adds to the security of the system but
instead this adds a costly PKI operation that would impact the time it
takes to establish a secure connection.

2. If there is an addition of certificated-based authentication (and
specifically for option #4 of PKI-based crews + AUTH_NONE) shouldn't
there be wording on what it means to do PKI-based authentication (the
whole fun of interpreting X.509-based certification etc).

3. This is about the wording of option #3 and specifically ".. doesn't
need to enable costly GSS integrity or privacy services". This to me
reads that GSS integrity/privacy services is more costly that doing
the same with TLS which I don't believe is a true statement. Shouldn't
it be something like "it can forego using GSS integrity/privacy
services because the transport layer already provides an encrypted
connection" or something of the sorts that say we don't need to do
integrity/privacy twice?

4. This is somewhat implementation specific question. If the draft is
introducing an AUTH_TLS RPC security mechanism, I assume in linux we'd
translate it to "sec=tls" option to be like other RPC AUTH mechanisms.
But "sec=tls" doesn't quite work, it better fits with the "proto=tls"
option group because "tls" by itself isn't enough. It'll always be
combined with a traditional "sec=sys" or "sec=krb5". Then we are
really introducing an option like "sec=tls+sys" or "sec=tls+krb5".
Then shouldn't we be introducing something like AUTH_TLS_SYS and
AUTH_TLS_GSS? Or if we are really talking about "proto=tls" (or
proto=dtls) do we even need AUTH_TLS and couldn't it be port-based
decision to support it or not (but yes I read the RFC 2595 that
discourages the use of "secure" ports as they could lead to user and
administrator misconceptions). To reiterate, I feel that if AUTH_TLS
is added but "sec=tls isn't used it would be confusing to users.

On Fri, Mar 29, 2019 at 10:18 AM Chuck Lever <[email-masked]> wrote:
>
>
>
> > On Mar 28, 2019, at 8:35 PM, Tom Talpey <[email-masked]> wrote:
> >
> >> -----Original Message-----
> >> From: Chuck Lever <[email-masked]>
> >> Sent: Thursday, March 28, 2019 3:43 PM
> >> To: Tom Talpey <[email-masked]>
> >> Cc: Lars Eggert <[email-masked]>; NFSv4 <[email-masked]>
> >> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> >>
> >>
> >>> On Mar 26, 2019, at 1:58 PM, Tom Talpey <[email-masked]> wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: nfsv4 <[email-masked]> On Behalf Of Chuck Lever
> >>>> Sent: Tuesday, March 26, 2019 1:52 PM
> >>>> To: Lars Eggert <[email-masked]>
> >>>> Cc: NFSv4 <[email-masked]>
> >>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
> >> 01.txt
> >>>>
> >>>>
> >>>>
> >>>>> On Mar 26, 2019, at 12:35 PM, Lars Eggert <[email-masked]> wrote:
> >>>>>
> >>>>> On 2019-3-26, at 17:33, Lars Eggert <[email-masked]> wrote:
> >>>>>> Also note that STARTTLS is somewhat less secure than running TLS
> >> directly.
> >>>> See for example Section 6 of RFC3207:
> >>>>>>
> >>>>>>  A man-in-the-middle attack can be launched by deleting the "250
> >>>>>>  STARTTLS" response from the server.  This would cause the client not
> >>>>>>  to try to start a TLS session.  Another man-in-the-middle attack is
> >>>>>>  to allow the server to announce its STARTTLS capability, but to alter
> >>>>>>  the client's request to start TLS and the server's response.
> >>>>>>
> >>>>>>  ...
> >>>>>
> >>>>> And RFC8314 recommends (for mail) that "implicit TLS" should be used
> >>>> instead of STARTTLS.
> >>>>
> >>>> Perhaps that is what we should require for RPC on TLS;
> >>>> that is, "STARTTLS MUST NOT be used"?
> >>>
> >>> It's a fine requirement, but there may need to be a justification for the MUST.
> >>>
> >>> It's important to note that such a requirement means you'll need to allocate
> >>> a new port number for such connections. This would apply to any upper
> >>> layer using the new RPC flavor, which in turn might impact the portmapper.
> >>> Note, it may also have implications on the proposed negotiation. If TLS is
> >>> a "done deal", negotiating the auth flavor may be moot.
> >>
> >> We could create a new netid for this purpose.
> >>
> >> Advertise an RPC program with this new netid, and no STARTTLS would
> >> be needed. The client simply connects and begins TLS negotiation.
> >
> > But, the current draft proposes using a new AUTH_TLS exchange, which
> > if successful allows the client to perform a STARTTLS. If you define a netid
> > and/or port number, the client would simply start in TLS, prior to even
> > sending its first RPC.
> >
> > Would that not simply make the whole draft unnecessary?
>
> No. The current revision places a number of restrictions on how TLS
> is used, and that is needed in any case. But, the draft could define
> new netids and reserve a new port number for making portmapper requests
> using TLS.
>
> Anyway, this is a strawman. I wanted to bring it up to ensure we are
> happy with using STARTTLS.
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Mon, 1 Apr 2019 13:50:33 -0400

Olga, thanks for your comments.

> On Apr 1, 2019, at 12:06 PM, Olga Kornievskaia <[email-masked]> wrote:
> 
> most useful option to be considered.

I quite agree that it is the most useful. I don't see where we are
specifically excluding that option, however.

> I don't see how adding

Self-signed certificates allow a form of weak authentication by the
server. At least it can audit which client is connecting. The
discussion of self-signed certs can be removed if it's not something
we want to explicitly commend.

It can be made a little more robust by using DANE, maybe.

> whole fun of interpreting X.509-based certification etc).

Feel free to propose text, or point us to an example discussion.

> the same with TLS which I don't believe is a true statement.

It is a true statement in the sense that TLS may be offloaded from the
host. Otherwise, I agree: if encryption is done by the host CPU, there
is going to be little or no difference in computational cost.

> Shouldn't

Sure, that's fair. I'll revise that text.

> really introducing an option like "sec=tls+sys" or "sec=tls+krb5".

This is an implementation issue rather than a protocol issue, of
course, but I don't feel that sec= makes sense at this point. We
are not changing the way RPC users are authenticated, which is what
sec= controls.

> AUTH_TLS_GSS?

No. The purpose of AUTH_TLS is simply to discover server support for
TLS. It is explicitly forbidden to be used after the TLS handshake.

> Or if we are really talking about "proto=tls" (or

See earlier parts of this thread. I think we are purposely trying to
avoid introducing new ports and portmapper dependencies. A netid-
based solution is probably a non-starter.

I expect we will add a family of TLS mount and export options to
control transport-level security, separate from transport protocol
and user authentication mode.

--
Chuck Lever

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 1 Apr 2019 16:31:49 -0400

> specifically excluding that option, however.

Ok I guess I have issues with wording. That section talks about "host
and user authentication". What is "host" here? Is this the NFS server
or is this a client machine where a "user" might execute NFS
operations? I really hope that "host" means an NFS server and it's the
NFS server that will be authenticated via TLS (which means a
server-side certificate will be used). That leads to Option 1 wording.
It's not clear which side would used a self-signed certificate and why
we right away restricting/suggestion the type of the certificate. I
think it would be better to say: "To establish a secure TLS connection
at least a server-side PKI certificate is required and can provides
server authentication. Statement: "end-to-end encryption is provided
client certificate material" ... I don't think that's what end-to-end
encryption typically means. I would rather say. "Mutual authentication
is provided when client also presents a PKI certification during a TLS
handshake." (or something of that sorts).

My wording of the options:
TLS server-side authentication only with AUTH_SYS identity: To
establish a secure TLS connection a server-side PKI certificate is
required and provides server authentication (either self-signed or
CA-certified certificates can be used). After TLS connection is
established, the RPC client uses AUTH_SYS to identify users with the
guarantee that the UID and GID values cannot be observed or altered in
transit.

TLS mutual authentication with AUTH_SYS:  During TLS negotiation, the
client identifies itself to the server with a PKI certificate.  As
with encryption-only with AUTH_SYS, UID and GID values are well
protected.  In addition, the server can use the client's PKI identity
to perform additional authorization of this client's requests.

TLS server-side authentication only with RPCSEC GSS Kerberos identify:
 To establish a secure TLS connection a server-side PKI certificate is
required and provides server authentication (either self-signed or
CA-certified certificates can be used). The RPC client uses Kerberos
to identify the client host and its users, but does not request GSS
integrity or privacy services as the connection is already secured.

TLS mutual authentication with AUTH_NONE:  Each user establishes her
own TLS context with the server, identified by a user PKI certficate.
There is no need for any additional information at the RPC layer, so
the RPC client can use the simplest authentication flavor for RPC
transactions.  This configuration is not typical for NFS deployments,
but it does enable strong certificate-based user authentication, which
is currently not afforded by GSS.

If by "host" you don't mean the "server" and mean client's machine.
And for the server we are not implying that it's OK to use self-signed
certificates (which I really hoped we were not suggestion).

Then the options I propose should be:
1. TLS server-side authentication + AUTH_SYS user identity: this is
the favorable option of no certificates on the client at all and only
server is authenticated.

2. TLS mutual authentication with machine certificates + AUTH_SYS user
identity . This is where I think a suggestion to use a self-signed
certificate can be made (however see my view below that I don't this
client-side authentication gains us anything).

3. TLS mutual authentication with user certificates + AUTH_SYS user identify

4. TLS mutual authentication with machine certificate + Kerberos user identify

5. TLS mutual authentication with user certificates + Kerberos user identify

6. TLS mutual authentication with user certificates + AUTH_NONE

> we want to explicitly commend.

In my personal option, adding self-signed (user) authentication
provides no benefits as there no attack that it protects from. We are
not proposing to use the identity gotten from the client-side of the
TLS connection and map it to an nfs4 identity, are we (cue in the SPKM
troubles here).

> Feel free to propose text, or point us to an example discussion.

Haha, sorry I probably shouldn't have said anything as I have nothing
of use to add. Andy and I wrote the SPKM spec and dealing with X509
identities is what killed it. Thus I don't know how to fix it. But I
strongly feel that using generic words for allowing PKI-based
authentication and not specifying the details might lead to
implementation problems.

> is going to be little or no difference in computational cost.

Hm, I'm curious where you would offload TLS (and specifically what)
and why can't we state that encryption operations can be offloaded for
the current implementation.

> are not changing the way RPC users are authenticated, which is what

You say you are not changing the way RPC users are authentication but
isn't the option of TLS authentication + AUTH_NONE indeed changes how
the RPC user is authenticated?

> TLS. It is explicitly forbidden to be used after the TLS handshake.

So by adding AUTH_TLS you are overloading what the "enum auth_flavor"
list provides. It lists authentication flavors so I feel it's a bit
sinister to use it for negotiation and not authentication.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 1 Apr 2019 18:58:38 -0400

> On Apr 1, 2019, at 4:31 PM, Olga Kornievskaia <[email-masked]> wrote:
> 
> server-side certificate will be used).

I thought that "host authentication" had an unambiguous meaning.
It means that the peer host is authenticated.

RPCSEC GSS performs host authentication using the service principals
on both peers.

With TLS, AIUI, the client can always authenticate the server, because
the server is required to have an identity (typically a certificate).
The server can authenticate a connecting client if the client has an
identity and presents it during the TLS handshake.

I can add "host authentication" and "user authentication" in the
Terminology section if people feel that would be helpful. Or should
I use "machine authentication" instead of "host authentication" ?

> That leads to Option 1 wording.

This appears to be based on an outdated version of this document.
The latest version is here:

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

I hope Section 4.2 of the latest revision answers your questions.

> TLS connection and map it to an nfs4 identity, are we (cue in the SPKM

IIRC we eventually decided not to support the use of user certs
for RPC on TLS.

> the current implementation.

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

> sinister to use it for negotiation and not authentication.

Can you elaborate on that?

--
Chuck Lever

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 2 Apr 2019 10:28:22 -0400

Hi Chuck,

First of all I apologizes for reading an out-dated version of the draft.

There are still several things I disagree with and some questions that I have:

1. Encryption offload. I think it's unfair to list this as a benefit
of switching to TLS from tradition encryption methods. TLS adds a very
costly operation (public key encryption) which to reduce the impact on
performance needs to leverage things like offload engines. The same
link talks about how all modern CPUs have hardware support for
symmetric key ciphers like AES which speeds things up. In my opinion,
this list item should be removed.
 -- what's a transient client?

2. "Per-client deployment and administrative costs are not scalable"
(I'm assuming it means deploying keytabs). Yet the spec is talking
about the use of host certificates. If existing design is not scalable
so will the design with host certificates (or user certificates) as it
requires the same deployment. In my opinion, this bullet should be
removed (and so it the 3rd list item that talks about CPU cost of
encryption).

3. Section 4.2.3 "Advanced forms of RPC authentication". I'm surprised
to see this here because of the wording in Section 1. Specifically it
says: "An alternative approach is to employ transport layer security
mechanism". Here alternative was to the GSS mechanism which was listed
as "hard to use". So nowhere was there a talk that TLS connection can
be used with a GSS mechanism. Is this section suppose to be about the
fact that RPCSEC GSS besides authentication also provides an encrypted
connection? Then I think the section title should be changed to
"RPCSEC GSS secure connection establishment"?   This section,blurs the
lines of RPC identify authentication via GSS identities and the TLS
authentication. In previous two section, it wasn't discussed what kind
of RPC authentication would happen on top of the TLS connection. I
think this whole section should be removed. Because it basically says
there is no need to use GSS privacy/integrity since underlying TLS
connection already provides that and since TLS is suppose to be
alternative to GSS so why combined it.

4. Section 5 is about TLS authentication and PKI identities. I find it
confusing the use of RPC client. RPC client has RPC identities from
the RPC RFC. Should we use TLS client here instead?

-- what is a TLS identifier? If it's defined in the TLS spec can we
either copy a definition or provide a reference for it?

-- If an (RPC/NFS) server suppose to make decisions about executing an
RPC/NFS request based on the PKI identify shouldn't there be a talk
about how to map the PKI identify into the NFSv4 identify?

 other comments in-line.

> I use "machine authentication" instead of "host authentication" ?

With the new organization of the draft I don't have those objections.

> IIRC we eventually decided not to support the use of user certs

I don't think that's true as the Section 5.2 talks it. While there is
definitely a lot more information about what should go into the user
certificate and a concrete PKI identity : "an RPC client is uniquely
identified by the tuple (serial number of presented client
certificate;Issuer)" there is nothing about how to map this to the
NFSv4 identify.

> Can you elaborate on that?

This is not all that important but something about this rubs me the
wrong way. "enum auth_flavors" list flavors for RPC identify
authentication. With AUTH_TLS we are not authenticating an RPC entity.
We are overloading it and providing transport layer security.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 2 Apr 2019 11:15:40 -0400

> On Apr 2, 2019, at 10:28 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> Hi Chuck,
> 

TLS offload actually exists. GSS does not give us any practical
path for offloading encryption and decryption. If an example of
a commodity part that provides GSS offload can be identified,
I'll consider removing this bullet.

> -- what's a transient client?

An example is a guest's laptop.

> removed (and so it the 3rd list item that talks about CPU cost of

Certificates on RPC clients are optional. In deployment scenarios
that don't provide client certificates, administrative cost is
lower.

I'll change the bullet to refer to "clients" instead of "host
systems".

> alternative to GSS so why combined it.

We have to discuss the use of channel binding somewhere, and
we have to discuss the double host authentication because TLS
has a host authentication step and so does GSS. I don't see any
discussion of user authentication here.

I'll change the section title.

> either copy a definition or provide a reference for it?

I'm looking for a generic term that encapsulates certificate,
PSK, or token binding to mean the identity of the peer host.
Anyone know of a appropriate term to use for that?

> about how to map the PKI identify into the NFSv4 identify?

RPC over TLS is strictly about encryption at the RPC layer. It
has nothing to do with the RPC user, and NFSv4 has no awareness
that TLS is in use at the transport layer.

The server may determine whether to accept or reject a connection
request based on the client's identity. That identity is not used
to authorize individual RPC requests.

> I don't think that's true as the Section 5.2 talks it.

Where? I see only discussion of the RPC client's identity.

> While there is

That's because the NFSv4 protocol is not aware of the use of TLS.
There is no connection between NFSv4 identities and TLS. If a user
certificate is employed, it is used strictly for host authentication.

--
Chuck Lever

---

From: Olga Kornievskaia <[email-masked]>
Date: Wed, 3 Apr 2019 12:12:38 -0400

> that don't provide client certificates, administrative cost is

Sure, but then please add explicitly to the 4.2.2 (mutual
authentication) that this mode adds to the deployment cost making it
equivalent to the existing GSS model.

> discussion of user authentication here.

I would have re-organized this to be something like:

4.2 Establishing an end-to-end encrypted channel
same paragraph as before about providing a transparent end-to-end
encrypted channel for the RPC operations.
4.2.1 TLS server-only authentication
(same as before)
4.2.2 TLS mutual authentication
(same as before)
4.3.3 Role of the RPCSEC GSS integrity and privacy services
Here talk about redundancy of using GSS services on top of TLS.
Channel binding would go here.

4.3 RPC authentication on top of an encrypted channel
Here talk about how any of the existing methods (AUTH_SYS, GSS) can be
overplayed on top of the encrypted channel.

> Anyone know of a appropriate term to use for that?

Sorry more question about section 5 "TLS peer authentication".  Is the
purpose here to describe how a server would authenticate the client or
how the client authenticates the server (or both). I think the
intention to handle "both". So if this section applies to both side
then the use "RPC client is uniquely identified by tuple" to me reads
to only apply to the RPC client. If this suppose to apply to both then
"TLS peer" maybe used? If this is suppose to be talking about just one
side authentication (whatever side that is), then why another side is
excluded (again I think it is both). Some of the bullets talk about
requirements for server authentication, but then there is wording that
server can deny

Also, for the "pre-shared" keys section can we add a reference to
RFC8446 section 2.2 otherwise there isn't much context here. Though I
feel that this draft was about making deployment easier so the cost of
pre-sharing the keys is like going backwards.

> Where? I see only discussion of the RPC client's identity.

Section 5.2 says "an RPC client is uniquely identified by the tuple
... ie certificate". To me this reads, a client has a user
certificate.  But this section doesn't talk about the self-signed
certs.

---

From: Tom Talpey <[email-masked]>
Date: Wed, 3 Apr 2019 16:46:24 +0000

> From: nfsv4 <[email-masked]> On Behalf Of Olga Kornievskaia
> Sent: Wednesday, April 3, 2019 12:13 PM
> To: Chuck Lever <[email-masked]>

Olga, I support this approach but would like to suggest it also explore the
inter-relation of existing RPC authentication methods with TLS. For example,
if per-user keys (obtained from the auth itself) are used to secure the TLS
channel, rather than the more usual machine-wide ones.

In addition there are implications on trunking and multiplexing of traffic,
and under what conditions traffic destined for a TLS channel can be redirected
and/or retried . For example, if GSS privacy is "downgraded" once a TLS channel
binding is established, then any trunked connections cannot be used until and
unless a similarly-protected TLS association is obtained on them as well. This
gets especially hairy in reconnection/retry scenarios.

Tom.

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-ietf-nfsv4-rpc-
> tls%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com%7C03bbacc8265a4
> 10c140508d6b84f3cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> C636899047801793678&amp;sdata=rTIELxr2yBE8vluAoCHkmZJXqd%2FwHV%
> 2F2BHblUvSCz3g%3D&amp;reserved=0
> > >>
> .... ie certificate". To me this reads, a client has a user
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fnfsv4&amp;data=02%7C01%7Cttalpey%40mi
> crosoft.com%7C03bbacc8265a410c140508d6b84f3cf2%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C636899047801793678&amp;sdata=7gZKwy
> NwPk7KqrbafSfzaFnP%2ByLVknRu0tqIprtpBZc%3D&amp;reserved=0

---

From: Chuck Lever <[email-masked]>
Date: Wed, 3 Apr 2019 13:47:48 -0400

> On Apr 3, 2019, at 12:12 PM, Olga Kornievskaia <[email-masked]> wrote:
> 

I'm not sure this warrants its own subsection. I'll look into
explicitly stating that RPC user authentication is not altered
by transport encryption earlier in Section 4.

Hopefully the new language will not forbid someday specifying
user authentication via certificates. For now I would like to
keep this document narrowly focused on providing transport
encryption.

> intention to handle "both".

It is both. I'll correct the text throughout Section 5.

> So if this section applies to both side

I've reread the first paragraph of Section 5.2.1. I'm still
not getting any sense that this implies a user certificate.

However I expect this text will change to accommodate
replacing "RPC client" with a term that means both peers.
Let's revisit with the next revision.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Wed, 3 Apr 2019 23:31:16 +0200 (CEST)

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "Olga Kornievskaia" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Wednesday, April 3, 2019 7:47:48 PM

> keep this document narrowly focused on providing transport

In GRID computing, dealing with end-user certificates is the main
reason why we try to move away from X509. Proxy certificates
with limited life time to pass around with, LDAP configs,
renewal, trusted CA distribution, CRLS, legal requirements to
present ID-card to get a certificate in the first place...
However, RPC is not only NFS. We have accelerator control systems,
that use AUTH_NONE with IP table rules. And, in general, many
server-to-server RPC based communication will benefit from
client+server mutual authentication. For example pNFS deployment,
where DSes talk to MDS and both want to be sure that the other
side is the right one.

IOW, don't require it, but keep it possible.

Tigran.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 4 Apr 2019 10:32:55 -0400

Hi Tigran-

> On Apr 3, 2019, at 5:31 PM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> that use AUTH_NONE with IP table rules.

Indeed, this is a use case that is interesting to me as well.
In cases where a transient cloud service is spun up that has
no local user identities, AUTH_NONE would be appropriate to
use.

> And, in general, many

This sounds like what Trond is most interested in.

> IOW, don't require it, but keep it possible.

I'm not sure exactly what you would like to see.

- The option to use user certificates for host authentication
  specified in this document.

- The option to use user certificates for host authentication
  left open for a future specification.

- The option to use user certificates for user authentication
  specified in this document.

- The option to use user certificates for user authentication
  left open for a future specification.

Enabling user certs at all seems like it could add significant
complexity to the document, and IIUC the use of user certs
might need some involvement with the protocol being carried
by RPC. That's why my preference would be to defer this
complexity to other specifications, if we can.

The next revision is evolving here:

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

The Editor's Copy is the latest work, and there is a link
under that to generate an rpcdiff with the revision that was
submitted earlier this week to the datatracker.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Thu, 4 Apr 2019 21:52:21 +0200 (CEST)

Hi Chuck,

----- Original Message -----
> To: "Tigran Mkrtchyan" <[email-masked]>
> Sent: Thursday, April 4, 2019 4:32:55 PM

> This sounds like what Trond is most interested in.

With a deployment dedicated CA it's an easy way to
control which hosts belongs to the instance. We do
it for our internal message communication.

>  left open for a future specification.

Let's have a look and HTTP-over-TLS (rfc2818). No special requirement
for client authentication. The TLS spec (rfc8446) says:

   4.3.2.  Certificate Request

      A server which is authenticating with a certificate MAY optionally
     request a certificate from the client. 

The combination of it I read as: server configuration controls is client
certificate requested or not. Thus, leave it to TLS configuration.

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.

Regards,
   Tigran.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 5 Apr 2019 10:35:39 -0400

> On Apr 4, 2019, at 3:52 PM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> Hi Chuck,
> 
> But what should be part of your document is the handling of TLS session

>   Client can terminate the TLS session after sending a TLS closure alert.

What if a client closes the connection without terminating
the TLS session?

>   will fail with AUTH_ERROR.

What about UDP with DTLS?

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Apr 2019 22:22:54 -0500

> What if a client closes the connection without terminating

Indeed, close_notify is basically unusable in the web world due to clients
just doing this.

> What about UDP with DTLS?

(There's not a reliable way to do so.)

-Ben

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 8 Apr 2019 17:53:41 +0200 (CEST)

Some performance numbers on Dell PowerEdge R510 E5645 2.40GHz, TCP, single client
single server over localhost sending op NULL:

Benchmark               (withTLS)   Mode  Cnt      Score     Error  Units
TlsOverhead.callOpNull       true  thrpt   25  12865.357 ± 135.963  ops/s
TlsOverhead.callOpNull      false  thrpt   25  12802.179 ± 156.782  ops/s

Looks like TLS overhead is ~0.5%. For each mode (with and without TLS) a 25 iterations of runs was performed.
Each each iteration was running for 10 seconds and calling op null in a loop.

Regards,
   Tigran.

----- Original Message -----
> From: "Benjamin Kaduk" <[email-masked]>
> To: "Chuck Lever" <[email-masked]>
> Cc: "Tigran Mkrtchyan" <[email-masked]>, "NFSv4" <[email-masked]>
> Sent: Saturday, April 6, 2019 5:22:54 AM