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

[David Noveck <[e-mail]>]

>
> > It didn't happen and the document has been approved.
>

> Actually, the document hasn't been approved.

My mistake.  My point to Nico was basically that it is past the point
(or at least should be)  past the point when new objections can
be raised.   I recognize the need to resolve existing objections.

I think Bruce's point is right and the authors could update the security
considerations section to point back to Section 5.

That assumes that nobody takes Nico's advice to reverse this part
of the xattrs design.  System xattrs, at least for now, were rejected
largely because they raised the kind of issues you were concerned
about.


On Mon, Jun 5, 2017 at 4:15 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Jun 5, 2017 at 9:30 PM, David Noveck <[e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>>
>