I support adoption of the document. To my perspective, holding code point allocation is likely to result in non allocated code points being used which represents a higher threat to interoperability than adding an algorithm. Standard track and MAY/OPTIONAL status seem reasonable to me
Yours, Daniel On Thu, Jun 18, 2020 at 12:58 PM Eric Rescorla <e...@rtfm.com> wrote: > > > 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 > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
