Re: [secdir] Secdir review of draft-murchison-nntp-compress-05

[Barry Leiba <[e-mail]>]

Hi, Julien, and thanks for the thorough response.

Further response only on the items where response is needed:

> Maybe you would prefer for our document:
>
>     Consequently, a server MAY list the AUTHINFO capability with
>     no arguments, or not advertise it at all, in response to a CAPABILITIES
>     command received from an unauthenticated client after a compression
>     layer is active
>
> This way, we would no longer use SHOULD, but MUST and one MAY.

It's a small point, but I don't like "MAY" to introduce two
alternatives, because it's not clear whether there might be other
alternatives as well... or not.  How does it work for you to make it
"MUST" instead of "MAY", saying, therefore, that the server MUST
either list AUTHINFO with no arguments or not advertise it at all?
Then it's clear that there are two alternatives, and either is OK.
No?

>>    When compression is active and either the client or the server
>>    receives invalid or corrupted compressed data, the receiving end
>>    SHOULD immediately close the connection.  (Then the sending end will
>>    in turn do the same.)
>>
>> Same question.
>
> We used SHOULD because RFC 4642 uses SHOULD in a in Section 2.2.2:

OK.

> I therefore also suggest to keep SHOULD here.
> Do you believe we should switch to MUST anyway?  (Wouldn't it be a
> too strong constraint?)

Well (and we're now down to nit level, so do as you think best here),
as I see it, it's not a question of level of constraint -- if it were,
you could say it without 2119 key words, as "the receiving end
immediately closes the connection, in response to which the sending
end will do the same."  (Now that I think about it more, I think
that's the best answer, but if you disagree that's fine.)

The (very, very small) problem I have with "SHOULD" here is that
"SHOULD" means that you really need to do it unless you have a good
reason not to and have considered the consequences of not doing it.
Along that line, what does it really mean for me *not* to close the
connection when I've received bogus compressed data?

> Wording suggested for our document:
>
>   This document defines the following new response code.  It is not
>   multi-line and has no arguments.
>
>    Response code 206
>       Generated by: COMPRESS
>       Meaning: compression layer activated

Parfait; merci.

> Je ne suis effectivement ni Shakespeare ni Molière :)

He-he...

>>    In case confidential articles are accessed in private
>>    newsgroups, special care is needed: implementations SHOULD NOT
>>    compress confidential data together with public data when a security
>>    layer is active, for the same reasons as mentioned above in this
>>    Section.
>>
>> Sorry: it is not clear to me what reasons those are; can you be
>> specific here?  And why SHOULD, and not MUST?
>
> ... because the reasons above do not strictly apply to that case.
>
> Suggestion:
>
>     In case confidential articles are accessed in private
>     newsgroups, special care is needed: implementations SHOULD NOT
>     compress confidential data together with public data when a security
>     layer is active.  As a matter of fact, adversaries that observe
>     the length of the compressed data might be able to derive
>     information about it, when public data (that adversaries know is
>     read) and confidential data are compressed in the same compress session.

That sounds great; thanks.

> I suggested SHOULD because I thought MUST was too strong.
> It would imply that clients and servers have a way to specify
> the confidentialness of newsgroups.  It currently does not exist,
> and I doubt a user would maintain it in its news client.

Yes, that makes sense.

>>    Additionally, implementations MAY ensure that the contents of two
>>    distinct confidential articles are not compressed together.
>>
>> Of course they MAY, but what's the point of saying that.  I think
>> you'd be much better off skipping the 2119 key word here, and instead
>> say something about why it might be good to do this: what's the
>> advantage?  Something like, "Additionally, implementations would do
>> well to ensure that the contents of two distinct confidential articles
>> are not compressed together, because [of this advantage]."
>
> We had in mind the following scenario:
>
> "[...], because adversaries might be able to derive information about
> confidential articles as they may have identical header fields (like
> Subject, Newsgroups or From) or header fields whose contents may be
> predictable (like Xref or Injection-Info)."
>
> Maybe "predictable" is not the right word.
> "have a structured pattern"?  "are formatted in a known syntax?"
>
> Examples:
>   Injection-Info: news.trigofacile.com; posting-account="eliej";
>         posting-host="news.trigofacile.com:2001:41d0:1:6d44::1";
>         logging-data="29828"; mail-complaints-to="[e-mail]"
>   Xref: news.trigofacile.com trigofacile.test:566
>
> Do you have a preferred wording for that paragraph?
> (Should a reference to RFC 5536 be also mentioned?  Like "These header
> fields are described in [RFC5536].")

As I say, maybe just drop the key word and say it without capitals.
If it's not easy to explain or determine, maybe just say that it's
good to do it if you can:

NEW
   Additionally, it is preferable not to compress the contents of two
   distinct confidential articles together if it can be avoided.
END

But, again, it's a small point that probably doesn't need further discussion.

> In the registry, it is indeed best to use upper case.  I can mention it.
>
> Just to be certain of the meaning of your remark:  the algorithm name
> in the NNTP command is not required to be upper case.
>
>      algorithm = "DEFLATE" / 1*20alg-char
>      alg-char = UPPER / DIGIT / "-" / "_"
>
> ABNF syntax is not case-sensitive, so "COmprESs dEFlaTe" is a valid
> NNTP command, that has the same effect as "COMPRESS DEFLATE".

Actually, that's an ABNF error that I missed: "DEFLATE" doesn't have
to be in upper case, but any *other* algorithm does (because
"alg-char" can only contain UPPER, not ALPHA or LOWER).  To fix that,
I suggest using this:

   algorithm = %s"DEFLATE" / 1*20alg-char

...and adding a normative reference to RFC 7405... that forces DEFLATE
to be upper case.  Unless, of course, you really want to allow
case-insensitivity here.  If that's so, you'll need to change the
definition of alg-char to use ALPHA, and you'll need to tell IANA that
all values should be converted to upper case when they're registered
(so that we won't wind up with "FLOOB" and "floob" both being
registered).

>> Oy.  This really sounds convoluted to me, and the "MAY, but SHOULD
>> NOT" is a direct contradiction.
>
> Just saying that an implementation has the possibility to do that (MAY)
> but is not encouraged to (SHOULD NOT).

But that's not what it says: "MAY" doesn't mean it's possible; it
means that the choice is entirely an option.  So what that's really
saying is that it's perfectly OK to do either, at your option... and
then making a fairly strong restriction against one of the options.  I
think that's poorly specified and can be confusing.

Considering what you say in your response after that, let me suggest
an alternative:

NEW
   If the server advertises a registered NNTP compression algorithm, it
   MUST implement the compression algorithm so as to fully conform with
   its related specification.  If it does not implement the compression
   algorithm as specified, the implementation is considered a private
   algorithm and MUST NOT be listed with the registered name in the
   arguments list of the COMPRESS capability label.

   Private algorithms with unregistered names are allowed, but SHOULD
   NOT be used because it is difficult to achieve interoperability with them.
END

How's that?

>>    A server MUST NOT send different response codes to COMPRESS in
>>    response to the availability or use of a private compression
>>    algorithm.
>>
>> I don't understand what this is saying at all.  Different from what?
>> Can you clarify this?
>
> Suggestion:
>
>     The 206, 403, and 502 response codes a news server answers
>     to COMPRESS using a private compression algorithm MUST have the
>     same meaning as the one documented in Section 2.2 of this document.

Ah, yes, very clear now.  Thanks.

> Thanks again for your valuable comments to help improve the quality
> of the document.

You're welcome; I'm glad they've been helpful.

Barry