On Fri, 16 Sept 2022 at 16:54, <[email protected]> wrote: > Tom, > > > <tp2> > > I was thinking that the IESG will complain at TLS being only 1.2, > > Don't think so. Please see: > https://datatracker.ietf.org/doc/bofreq-dekok-bofreq-dekok-radius-extensions-and-security-00/ > .
Yes, TLS 1.2 can be continued to be used by existing protocols following the recommendations in https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-11. The BCP allows implementations to use TLS 1.2 and encourages them to mitigate to TLS 1.3. -Tiru > > > Cheers, > Med > > > -----Message d'origine----- > > De : OPSAWG <[email protected]> De la part de tom petch > > EnvoyΓ© : vendredi 16 septembre 2022 12:13 > > Γ : Joe Clarke (jclarke) <[email protected]>; [email protected] > > Objet : Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for > > Encrypted DNS > > > > From: Joe Clarke (jclarke) <[email protected]> > > Sent: 15 September 2022 20:57 > > > > <tp2> > > My ever helpful webmail just changed the layout, without warning, > > to make it much harder to use so while the content of my replies > > does not change, where they go may be somewhat random - currently > > I have 80 options but no send button > > > > <tp> > > > > RFC6614 is a Normative Reference. This is Experimental and is > > TLS1.2 only > > > > JMC> Good point. I don't think it needs to be normative for > > implementation of this work. > > > > <tp2> > > I was thinking that the IESG will complain at TLS being only 1.2, > > be it Informative or Normative. I think that the TLS WG have > > created a mire with TLS1.3 being so different that adoption will > > be very slow so the real world of Enterprise will see 1.2 as a > > MUST while the IESG sees 1.2 as NOT RECOMMENDED as we will be here > > for some time to come. (A bit like IPv4 and IPv6:-( > > > > Lots of mentions of TBAn with n from three to seven with 'see > > section 6.2' where there is no mention of them. > > > > JMC> I saw those, too and almost commented. I think Qin may have > > mentioned it. Instead of reusing the TBAs, the authors used > > Section numbers in the IANA considerations. Using them as well > > would add clarity. > > > > <tp2> > > > > But are TBA3 et al. meant to be assigned by IANA? If so , IANA > > should be told (good as IANA are as interpreting our sloppy work). > > > > Tom Petch > > > > Joe > > > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
