Chris I have just been reminded of another potential spanner in the works.
TLS uses certificates but what they contain and how that information is used varies widely. Earlier this year, we got RFC6125 (not sure what we did to deserve it) which lays down rules on how to check a server certificate, such as pouring cold water on the use of CN, which s7.2 of this I-D mandates. In general, 'x over TLS' I-D and RFC go into a lot more detail than this I-D does. Pessimist that I am, born of bitter encounters with security paragons, I would expect some push back in this area. Is this something to bounce off a relevant party, such as a member of secdir, as you did with MD5 et al? I am looking at s7.2 and thinking that it will be found wanting, compared to, say, RFC5539 s.3. Tom Petch ----- Original Message ----- From: "t.petch" <[email protected]> To: "Christopher Morrow" <[email protected]>; "Joe Touch" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Tuesday, September 27, 2011 9:51 AM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > Chris > > Joe also made the point that the Service names as currently specified have an > invalid syntax in that there is a space in there, so that needs fixing, I think > before an IETF LC. > > Tom Petch > > > ----- Original Message ----- > From: "Christopher Morrow" <[email protected]> > To: "Joe Touch" <[email protected]> > Cc: <[email protected]>; "Paul Hoffman" <[email protected]>; > <[email protected]> > Sent: Monday, September 26, 2011 3:44 PM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch <[email protected]> wrote: > > > > > > On 8/24/2011 3:57 PM, Paul Hoffman wrote: > >> > >> On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: > >> > >>> On 8/24/2011 1:27 PM, Paul Hoffman wrote: > >>>> > >>>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: > >>>> > >>>>> Is there ever a reason that this service should exist as a totally open > >>>>> and insecure port? > >>>> > >>>> Given that it is explicitly listed in the draft, I find it worrisome > >>>> that you even ask the question. > >>>> > >>>> Caches and routers MUST implement unprotected transport over TCP > >>>> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators > >>>> SHOULD use procedural means, ACLs, ... to reduce the exposure to > >>>> authentication issues. > >>> > >>> I saw a declaration that this was required, but no REASON that > >>> unprotected transport was necessary. > >> > >> Three paragraphs earlier in the document: > >> > >> Unfortunately, > >> there is no protocol to do so on all currently used platforms. > >> Therefore, as of this document, there is no mandatory to implement > >> transport which provides authentication and integrity protection. > > > > I recall that discussion, but not the assertion that this would mean that > > you'd suggest using an insecure port. > > > > If that's the case, I strongly recommend NOT asking for a system port. > > > >> This was discussed heavily in the WG. > >> > >>>>> Also, is there a reason for not assuming that the out-of-band and > >>>> > >>>> in-band services cannot exist on the same port (other than performance > >>>> of the connection establishment)? > >>>> > >>>> Those aren't enough !?!? > >>> > >>> "those"? I listed only one - performance. > >> > >> Sorry, I misread your parenthetical as "other than performance and > >> connection establishment". The idea that you can do TLS on the same port > >> as not-TLS has been widely debated. It was finally agreed (maybe not by > >> you) that the STARTTLS method for sharing a port may or may not be > >> appropriate for each protocol. When I look at this protocol, I do not > >> see a way to do it without completely rewriting the protocol interactions. > > > > Here I wasn't asking about TLS vs open, I was asking about TLS vs. > > IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. > > > > Whether for this protocol or not, I would appreciate understanding that in > > more detail - even if off-list. I cannot see how the protocol matters if TLS > > is started or not on a per-connection basis since the TLS would wrap (or > > not) the data of the connect at the start. We can continue that off-list, > > though. > > The doc in question hit version 16 on 8/13/2011... I think the authors > feel that the problems/issues/discussion-points here are addressed in > this version. Are we cycled down to acceptance of the language or no? > The -16 version asks for a 'well-known' port, which gets to the main > point of this discussion I think. > > (and an IANA request would still need to be made when the doc goes > toward publishing) > > -Chris > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
