Subject: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Nov 2017 20:37:58 +0000

Hiya,

I just posted a draft shepherd write-up for this [1]. (The
write-up text was mostly written by Sean as it happens - for
which he has my thanks as it's boring as hell to do that:-)

There are nits but only one substantive question that I don't
recall the WG discussing before (but maybe I'm forgetting).

What is needed to change from Recommended == Yes down to
Recommended == No? Does that need a standards action (e.g.
with an RFC) or just IETF review or even maybe just IESG
action?

In the current draft write-up I've put in the first as a
placeholder, as that's symmetric with the No->Yes change but
I think IESG action is probably ok if the WG wanted that as
the IESG probably won't go crazy and will likely do as the
WG want in such cases. If the WG do want to write a specific
foo-no-longer-recommended RFC it can do that in all cases,
and of course Yes->No transitions could be documented in an
RFC that documents a "replacement" Yes entry.

So, unless this was already discussed....answers on a postcard
please - which'd we like:

(1) say nothing (as in -02 draft)
(2) say standards action is required for a Yes->No transition
(3) say IETF review (i.e. an IETF last call) is required for a
    Yes->No transition
(4) say IESG action is required for a Yes->No transition
(5) something else

And as a reminder the Recommended column is not about crypto
quality but is about things for which we have consensus that
they ought be widely implemented and available at the current
point in time. Those are related things but Recommended == No
does not imply crap-crypto even if crap-crypto will hopefully
imply Recommended == No.

If nobody says anything I'll chat with Kathleen, Sean and Joe
and we'll pick a thing and that'll doubtless be quibbled about
during directorate reviews and IESG processing as these things
always are;-)

But since I'd hope implementers will care about keeping up to
date with the set of Recommended == Yes things, I do hope that
folks are willing to express a preference here.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Nov 2017 10:39:40 +1100

IESG action seems appropriate for both.  If we could include guidance
around this (values with Yes should only include those for which the
community currently has consensus are worth having available at the
current time), tat would be awesome.

On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Nov 2017 23:54:42 +0000

On 21/11/17 23:39, Martin Thomson wrote:
> IESG action seems appropriate for both.  

I'm fairly sure the WG discussed the No->Yes (or new Yes)
before and wanted standards action for that. I'd guess
that changing that might take some discussion. (FWIW, I'd
not support that change myself but maybe others would.)

If the No->Yes stuff doesn't change I'll take you as
arguing for a (4) below but correct me if that's wrong.

Cheers,
S.

> If we could include guidance
> current time), tat would be awesom>

---

From: Sean Turner <[email-masked]>
Date: Wed, 22 Nov 2017 12:13:23 -0500

Funny I never thought about going down, but I guess we should ;) I think the premise we want here is hard to get a Yes (whether new or upgrade) and somewhat easier than that to go down but it can’t be done in the dark so 4 would work. This kind of works out because people are motivated to get ciphers specified, but very much less so to de-specify them.

spt
> On Nov 21, 2017, at 18:54, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Nov 2017 14:08:39 -0500

IESG approval seems also fine to me. Hopefully ciphers may not be used at
the time they are deprecated.

Yours,
Daniel

On Wed, Nov 22, 2017 at 12:13 PM, Sean Turner <[email-masked]> wrote:

> Funny I never thought about going down, but I guess we should ;) I think
> the premise we want here is hard to get a Yes (whether new or upgrade) and
> somewhat easier than that to go down but it can’t be done in the dark so 4
> would work. This kind of works out because people are motivated to get
> ciphers specified, but very much less so to de-specify them.
>
> spt