Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS

On Fri, 16 Sept 2022 at 16:54, <mohamed.boucadair@orange.com> 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 <opsawg-bounces@ietf.org> De la part de tom petch
> > Envoyé : vendredi 16 septembre 2022 12:13
> > À : Joe Clarke (jclarke) <jclarke@cisco.com>; opsawg@ietf.org
> > Objet : Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for
> > Encrypted DNS
> >
> > From: Joe Clarke (jclarke) <jclarke@cisco.com>
> > 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
> > OPSAWG@ietf.org
> > 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>