Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

> On Dec 23, 2020, at 7:03 PM, Rick Macklem <[e-mail]> wrote:
> 
>> And, we agree that securing single-user clients is an important
>> use case. (paraphrase. My stupid email system cut the text line out.)
>> 
>> I expect other implementers will find the same thing. When they
>> deal with this issue, they might see your implementation and
>> and copy it. Or they might copy it and add some variations,
>> since there is no published specification.
> Yes. As above w.r.t a TLS squashing data and distribution mechanism,
> I agree.
> 
>> And then I can see one or more of them approaching the WG and
>> asking us to either update rpc-tls or provide a specification
>> to enable proper interoperation.
>> 
>> Or, possibly, at some point in the future, the WG will be tasked
>> with updating rpc-tls to reflect implementation practice, part
>> of which might be otherName.
> And you can simply restate that you do not consider use of the
> otherName field this way as acceptable, due to conflagration
> of user and machine credentials in the certificate.

> (I suppose there is the question of whether or not the "collective"
> working group agrees with the above, but since no one else has
> commented except Ben Kaduk, we do not know the answer to
> that?)

I think we know the answer. We have a consensus that was
arrived at by the usual process. It is documented in
rpc-tls.


> Any other implementation who might choose the otherName
> approach can easily do so from the FreeBSD doc. and sources.
> (Or by simply asking me.)

My concern is that we have a spec (one that supposedly
represents a community consensus) that tells us not to mix
client and user authentication material, and yet implementers
are choosing to do this anyway.

Is the spec then wrong? If it is, the WG needs to address that.
The primary purpose of specifications is to codify the practices
where we agree, yet there is clearly a disagreement already.

If the spec is not wrong, the WG needs to consider ways to
address the need while complying with the normative
requirements in rpc-tls.

I was hoping that we could identify a compromise position, at
least, with the FreeBSD implementation. If it turns out we
cannot, then the WG needs to construct a proper response to
the single-user-per-client scenario.

In short, the WG must come to a fresh consensus that either
otherName is OK to do in this scenario, or it must provide an
acceptable alternative.


>> At that point, we have a real problem. Or maybe just me, as an
>> author of rpc-tls and possibly its descendants, has that problem.
> I do not really see the problem. No is a simple answer.

Simple, but problematic. The possible result will be the
promulgation of implementations that do not comply with our
shiny new specification. I think the IETF would view that as
very much a quality-of-specification problem. The usual redress
is to publish an updated protocol specification.


--
Chuck Lever