Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla <[e-mail]>]

On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters <[e-mail]> wrote:

> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>
> > The way that TLS has handled this is to have the registries have a
> column called Recommended and we just mark things Y or N. This is slightly
> > different from RFC 2119 language.
> >
> > It's not that uncommon to have new stuff introduced with Recommended =
> N. In fact this is the likely outcome for the GOST cipher suites:
> > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/
>
> I don't see anything like that mentioned in the IANA Considerations
> section?
> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>

The relevant text is in 8447: https://tools.ietf.org/html/rfc8447#section-5

   Per this document, a "Recommended" column has been added to many of
   the TLS registries to indicate parameters that are generally
   recommended for implementations to support.  Adding a "Recommended"
   parameter (i.e., "Y") to a registry or updating a parameter to
   "Recommended" status requires Standards Action.  Not all parameters
   defined in Standards Track documents need to be marked as
   "Recommended".

As the GOST draft has an informational header and is not a TLS WG
item, I would expect any registration to have Recommended = N.



In fact, the table is specifically missing the Recommended column
> required by the IANA Registry.
>

That seems like an omission but given the above, I expect IANA can handle
it.



> As a side not, in those Security Considerations I see:
>
>     2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
>     reasons for this restriction are that the 0-RTT data is not forward
>     secret and is not resistant to replay attacks
>
> It seems that the SHOULD NOT is really a very hard MUST NOT.
>

It's not clear to me if GOST is any different than the existing TLS cipher
suites in this respect, but if not, then I'm not quite sure what the
rationale is here.

-Ekr


> As another side note, would be nice to have a link to the IANA sections
> updated in the IANA Considerations Section.
>
>
> Paul
>