Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-xattrs-05: (with DISCUSS)

On Mon, Jun 5, 2017 at 9:30 PM, David Noveck <davenoveck@gmail.com> wrote:

> > I see a "system xattrs" extension in NFSv4's future.
>
> I don't and a lot of other people don't but if you want to propose one,
> you can.
>
> > You should at least allow for namespace reservations for system xattrs.
> > I notice you didn't.  Do it now, while you still can!
>
> As I understand it, the last chance to make this sort of change without
> major
> disruption to the process was when WGLC ended in December 2016.  The
> review of
> the document past that point proceeded on the understanding that only
> user xattrs
> would be supported and that fact was an important part of the authors'
> response to
> some of the security concerns that had been raised during IESG
> evaluation.
>
> > I hope some AD makes that a DISCUSS.
>
> It didn't happen and the document has been approved.
>

Actually, the document hasn't been approved. I'm still holding a discuss
pending
resolution of this topic. As I think I made clear in my discuss, I think
it's fine for
you to document this issue (or explain why it's not so) but the document
does
in fact need to do so.

-Ekr

>   I'm not sure exactly what
> changes are being awaited before the announcement is sent out but I don't
> expect that
> a late DISCUSS asking for inclusion of  system xattrs is among them.
>
> On Mon, Jun 5, 2017 at 2:56 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>
>> On Mon, Jun 05, 2017 at 02:39:38PM -0400, J. Bruce Fields wrote:
>> > On Thu, May 25, 2017 at 01:22:47PM -0500, Nico Williams wrote:
>> > > On Thu, May 25, 2017 at 09:11:53AM -0700, Marc Eshel wrote:
>> > > > We had a lot of discussions in the WG about the security
>> implications and
>> > > > we decided to stay a way of defining different types of xattr. This
>> is
>> > > > user only xattr for the applications to use and it should be
>> handled as an
>> > > > extension to the data in the file without any meaning for the
>> protocol. If
>> > > > it is not clear enough we can fix the text and add a warning.
>> > >
>> > > That's fair, but the point is that the security considerations should
>> be
>> > > very explicit as to this.  MUST/MUST NOT language is called for.
>> >
>> > https://tools.ietf.org/html/draft-ietf-nfsv4-xattrs-05#section-5
>> >
>> > "Xattr keys and values MUST NOT be interpreted by the NFS clients and
>> > servers"
>> >
>> > (and the rest of that paragraph).
>>
>> I see a "system xattrs" extension in NFSv4's future.
>>
>> You should at least allow for namespace reservations for system xattrs.
>> I notice you didn't.  Do it now, while you still can!
>>
>> I hope some AD makes that a DISCUSS.
>>
>> If it fell on me to add system attrs later, I might just store them
>> normal xattrs signed by a "system" key.  That actually may well be the
>> best way to do it in any case[0], in which case allowing this I-D to
>> proceed without even a namespace reservation would probably be fine.
>> However, I think it makes sense to make sure that you're not painting
>> yourselves into a corner, and that should be done now, not later.
>>
>> [0]  I doubt it.  For one, it creates yet another key management problem
>>      that we should all rather not have.
>>
>> Nico
>> --
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>
>