On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters <p...@nohats.ca> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
