Hi Eric, In response to your 2 questions below:
1. Should they be marked "Recommended" in the registry? [NCW] No, these cipher suites should not be “Recommended” in the registry. 1. Should the TLS WG spend time reviewing these documents? [NCW] I am not sure what you mean (intent-wise) by the question. Given there has been good feedback in the TLS WG thread.. that we will react to and update the draft accordingly; we can certainly include other applicable use cases as noted by some in the thread. Lastly, we’d like to the draft published as informational as we expect those with appropriate use cases to employ these ciphers. So, procedurally, I think some review of (and authors updating) the draft would be warranted? Warm regards, Nancy From: TLS <tls-boun...@ietf.org> on behalf of Eric Rescorla <e...@rtfm.com> Date: Tuesday, August 21, 2018 at 11:20 To: "<tls@ietf.org>" <tls@ietf.org> Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni <ietf-d...@dukhovni.org<mailto:ietf-d...@dukhovni.org>> wrote: > On Aug 21, 2018, at 1:29 PM, Ted Lemon > <mel...@fugue.com<mailto:mel...@fugue.com>> wrote: > > You're going to have to change what you do anyway—rather than arguing with > us why not bypass us entirely? TLS is not just a WWW protocol. Other transport security use-cases should not have to justify their existence. It is, of course, appropriate to make sure that proposed TLS code-points that cater to specialized needs are well thought out and include suitable security considerations. It is also reasonable to check that the requirements are not already met without the proposed code-points. I am concerned that we are going beyond that to questioning the legitimacy of the use-cases. IPsec is rarely a practical alternative to TLS. That said, TLS-LTS (a TLS 1.2 profile) may well be a good long-term choice where TLS 1.3 is not sufficiently compatible. As for TLS 1.3, it is indeed missing both null encryption and null authentication ciphers. If by "null authentication" you mean "without certificates", then TLS 1.3 does support these via RFC 7250. See: https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.5 This is not to say that null encryption ciphers for TLS 1.3 are unconditionally good, their specification would need to provide sound security considerations and be fit for purpose. But I do think that we should not reject the proposal out of hand. This isn't a matter of rejecting or accepting them. As I said at the beginning of this thread. No TLS WG approval is required to get a code point. The relevant questions are: 1. Should they be marked "Recommended" in the registry? 2. Should the TLS WG spend time reviewing these documents? Can the authors of this draft please say what they are looking for here? -Ekr -- -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
