Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Chuck Lever <[e-mail]>]

> On Sep 1, 2020, at 1:10 PM, Chuck Lever <[e-mail]> wrote:
> 
> 
> 
>> On Sep 1, 2020, at 12:09 PM, Benjamin Kaduk <[e-mail]> wrote:
>> 
>> On Tue, Sep 01, 2020 at 11:06:18AM -0400, Chuck Lever wrote:
>>> 
>>> 
>>>> On Aug 31, 2020, at 4:44 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>> 
>>>> On Mon, Aug 31, 2020 at 11:06:51AM -0400, Chuck Lever wrote:
>>>>> Hi-
>>>>> 
>>>>> I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
>>>>> current Editor's Copy with these changes can be found here:
>>>> 
>>>> Hmm, not quite -- the RFC 5487 ciphers are not compatible with TLS 1.3,
>>>> since TLS 1.3 redefines what a ciphersuite is (which also means that TLS
>>>> 1.3 provides native support for PSK handshakes), so you still need to
>>>> update Section 5.2.2 of this draft to refer to RFC 8446, removing the 4279
>>>> and 5487 references.
>>> 
>>> Whoops. A recent bad change needs to be reverted there.
>>> 
>>> NEW:
>>> 
>>> 5.2.2.  Pre-Shared Keys
>>> 
>>>  This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
>>>  is uniquely identified by keying material that has been shared out-
>>>  of-band or by a previous TLS-protected connection (see Section 2.2 of
>>>  [RFC8446]).  At least the following parameters of the TLS connection
>>>  SHOULD be exposed to the RPC server:
>>> 
>>>  *  The IP address of the peer that presented the certificate
>> 
>> In PSK mode, there may not be a certificate (though there can be, in
>> various scenarios).
> 
> And perhaps the IP address of the peer has changed since the PSK
> was originally exchanged.
> 
> 
>>>  *  TLS Identifier
>> 
>> Is this the PSK identifier or some other (TLS Exporter-generated?) value?
> 
> Not clear to me that we need to define a TLS Exporter.
> 
> I think the only use for the identity information is to authenticate
> the peer. We're not trying to use the PSK material for anything else.
> 
> So we want something that indicates that "this peer is the same peer
> we contacted when the PSK was originally exchanged."

This replacement for the Pre-Shared Key section might address
your comments here and in the COMMENT ballot position:

NEW:

5.2.2.  Pre-Shared Keys

   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
   can be uniquely identified by keying material that has been shared
   out-of-band (see Section 2.2 of [RFC8446]).  At least the following
   parameter of the TLS connection SHOULD be exposed at the RPC layer:

   *  PSK Identifier


--
Chuck Lever