Thu, Jun 30, 2022 at 07:09:14PM +0000, heasley: > Thu, Jun 30, 2022 at 03:05:33PM +0000, Joe Clarke (jclarke): > > [JC] As chair, I will call for adoption of this work by the WG. I read > > Alan’s recent reply and understand how he feels concerning this approach to > > more of a straight TLS encap around T+. I would like to hear what others > > in the WG think.</chair> > > Speaking for myself only; I might have misunderstood this point of Alan's > and will have to review that email. I think that the approach is > straight-forward; start tls, once established, start tacacs, tacacs, end > tacacs, end tls. How much easier could it be. > > We did specify a few TLS constraints, that Alan questioned. We're open to > discussing those details, but I think we need input from more tls experts > and believe this can occur after adoption. IIRC, that was our response at > the beginning of May when the composite draft was submitted.
Hey Joe. We reviewed the emails and draft and have concluded that we do not understand what you mean by "more of a straight TLS encap around T+." The proposal is as I suggested above. https://www.ietf.org/id/draft-dahm-tacacs-tls13-00.html There is text or lack of regarding SNI, resumption ticket lifetime, and 0RTT data that Alan has commented about, but otherwise nothing unusual. We believe the text is correct but are not TLS experts and think that these can wait for adoption. Please explain which part is not straight. Are you perhaps refering to a part of the other draft? https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs-security/ Thanks _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
