Re: [Rfcplusplus] labeling/experiments/ and ramifications

[Eric Rescorla <[e-mail]>]

On Wed, Jul 4, 2018 at 6:22 AM, Eliot Lear <[e-mail]> wrote:

> Hi Eric,
> On 04.07.18 14:52, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear <lear=[e-mail].
> org> wrote:
>
>>   So do encryption algorithms.  WRT what EKR said, it seems better to
>> have the algorithm documented than not, if it is being used.  The test: is
>> it really being used?
>>
>
> I want to narrow my response to this point: what we've done in TLS is
> allow code point registration with any stable reference, internal or
> external. This includes an I-D. We didn't make this change primarily in
> order to address the issues raised by this BOF, but I do think it was a
> good change. Can you explain why you don't think that this suffices?
>
> I wasn't really thinking in terms of code points when I wrote that, but
> since you asked: "Any stable reference" sounds fine.  Journal references in
> the face of scribd and DOIs are pretty cool these days.   A nit: we don't
> normally count I-Ds in that group, and the boiler plate explains why:
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>
> They are not intended to be stable references.  One way we know this to be
> the case is that they may not be normatively referenced, and most notably,
> they're supposed to expire, and can be rev'd leading to some amount of
> confusion if you then don't do another code point assignment.
>

I am aware of this boilerplate, but I don't think it comports well with the
way we actually handle IDs, which is that they stick around on the IETF
site forever. Remember, the only purpose here is that when you see the code
point on the Internet, you know what it means. As for the reving issue,
that's addressed by referring to a specific version.

I would note that
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
encodes this practice and it's currently in the RFC-Ed queue, so if you
object, you ought to do it soon.


> What I was thinking about: I'm not sure that this is just about a code
> point reference.  It's also about providing access to information by which
> others can assess the value of the algorithm.  Yes, there are other venues,
> but as you yourself pointed out, there really hasn't been any harm in
> having the algorithm published as an RFC:
>
>
> It does seem to me that for
>> national algorithms, they will be in the libraries anyway because
>> they will be mandatory procurement requirements.
>
>
> That's certainly an understandable prediction, but I haven't found it to
> be true in practice.
>
>
> Not a great demonstration of brand dilution, right?
>

Well, maybe. We got requests to implement these, and the fact that they
were RFCs and in some cases standards track RFCs was, IIRC, used as an
argument. However, we also felt we could say "no". However, I've also seen
algorithms in libraries (including NSS) mostly because someone decided to
do as much as was in some set of RFCs, so practices differ, even within
projects.

-Ekr