Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Ben,

Please can you update your position on the document? 
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/


Cheers

Magnus Westerlund

> -----Original Message-----
> From: Magnus Westerlund
> <magnus.westerlund=[e-mail]>
> Sent: den 23 juni 2020 13:56
> To: Magnus Westerlund <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
> DISCUSS and COMMENT)
> 
> Hi,
> 
> I think the new text on the CA looks reasonable as providing a context for
> the certificate validation text.
> 
> Ben, can you please check if the document resolves your discuss now?
> 
> Cheers
> 
> Magnus Westerlund
> 
> > -----Original Message-----
> > From: dtn <[e-mail]> On Behalf Of Magnus Westerlund
> > Sent: den 8 juni 2020 10:00
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail];
> [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: [dtn] Benjamin Kaduk's Discuss on
draft-ietf-dtn-tcpclv4-18:
> > (with DISCUSS and COMMENT)
> >
> > Hi Ben and Brian,
> >
> > On Fri, 2020-06-05 at 11:00 -0700, Benjamin Kaduk wrote:
> > > Hi Magnus, Brian,
> > >
> > > Sorry for the slow response here -- I've been trying to meet a
> > > deadline at work and email responses have suffered.
> > >
> > > I think Brian's discussion and explanations in this thread are
> > > generally spot-on.  I'll make a few notes inline but they don't really
> > > touch on the core substance of things.
> > >
> > > I do wonder, though (Magnus), why you are under the impression that
> > > (as stated in the start of the thread) " for normal Web PKI if a
> > > browser opens a connection for alice.foo.com and gets a cert that says
> > > foo.com and has a
> > > AltSubjectName: alice.foo.com it will be fine. However, if I put in
> > > alice.bar.com which is not a subdomain of the primary name in the cert
> > > it will reject the altSubjectName."  My understanding matches Brian's
> > > that all SANs and the CN are treated independently (and in particular,
> > > that if SANs exist, they are generally preferred over CN).
> >
> > Yes, I guess I made an error in though here. So maybe the better
question
> is
> > what type of runtime validation that is done related to domain names on
> the
> > certificate and its chain, any at all? Or is all this checking happening
> by the
> > enitity signing the certificate in the certificate chain?
> >
> >
> > What appear clear is that we really should keep the basic checking
> required
> > for any TLS usage in TCPCLv4 document seperated from what would be
> > required for any type of PKI for the DTN or IPN namespaces.
> >
> > I think the immediate question here boils down to what are the aspect
> > around this that we need to note in the TCPCLv4 document? I do note that
> > some of it is inlide below.
> >
> >
> > >
> > > [more inline]
> > >
> > > On Tue, Jun 02, 2020 at 12:58:43PM +0000, Magnus Westerlund wrote:
> > > > Thanks Brian,
> > > >
> > > >
> > > >
> > > > I think what you write below are quite clear. And I think has
> > > > reasonable security policies and a particular set of properties.
> > > > However, I don't think either Section 4.4 or the Security
> > > > Consideration goes into these. They support these but appear to have
> > > > more fluid boundaries to even more policies. So the question is if
> > > > the specification should be more articulate about these two targets
> > > > and state that additional security policies with associated
> > > > properties can be defined later either in implementation or future
> > documents.
> > >
> > > I still have an action item to read the updated I-D, and will try to
> > > keep this topic in mind as I do so.
> > >
> > > >
> > > >
> > > > Cheers
> > > >
> > > >
> > > >
> > > > Magnus
> > > >
> > > >
> > > >
> > > > From: Brian Sipos <[e-mail]>
> > > > Sent: den 1 juni 2020 18:57
> > > > To: Magnus Westerlund <[e-mail]>;
> > > > [e-mail]; [e-mail]
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > >
> > > >
> > > > Magnus,
> > > >
> > > > To clarify two distinct use cases for TCPCL security:
> > > >
> > > > 1.	On a private network, with private PKI and control of a CA:
> > > > In this situation I see it more as the CA's obligation to coordinate
> > > > with the network designer so that when a new BP Node is allocated
> > > > that it gets proper BP configuration, TCPCL configuration, and a TLS
> > > > certificate (to authenticate the Node ID URI) is produced. The
> > > > validation of its identity and private key occurs via side channels
> > > > the same way the Node is otherwise managed and configured.
> > > > 2.	On a more open network, where some other organization
> > controls PKI
> > > > roots and signing CAs:
> > > > In the near term, public CAs only know how to validate DNS names and
> > > > are likely only willing to sign certificates with DNS name SANs. In
> > > > this case
> > >
> > > I don't think this is quite true, depending on how you define "public
> CAs".
> > > There's a very long thread (including, unfortunately, a lot of
> > > redundant bits where people are talking past each other) on a similar
> > > topic, what it means to be a "public CA", and what "public CAs"
> > > currently can and are
> > > (not) willing to do, in the thread at
> > >
> >
> https://mailarchive.ietf.org/arch/msg/emu/8G6q7TnhgixgS92QWBNqL7vWd
> > 2U/
> > >
> > > Key topics include the need for an agreed set of rules for CAs to
> > > operate by in order for consuming applications to put trust in the
> > > certifications coming out of the CAs.  That is, a sense that if the
> > > rules are followed, then clients will get the properties they need by
> > > trusting the CA signatures.  And, of course, enough people doing
> > > enforcement that CAs actually follow the rules properly, to keep
things
> > working right.
> > >
> > > We're thinking about potentially having a future SAAG talk about
> > > non-web PKI topics (and if there's guidance we can/should give for
> > > starting such an ecosystem).
> > >
> > > > the CA doesn't know or care about the Node ID and any BP Node which
> > > > authorizes transfers to/from a TCPCL entity with a DNS-only
> > > > authentication just has to have an implicit trust that an
> > > > authenticated DNS name will not falsely claim a Node ID. This risk
> > > > is identified in Section 8.8 "Threat: BP Node Impersonation" [1] and
> > > > a BP Node can choose accept this risk as a policy decision.
> > > >
> > > > I think both of these situations are reasonable if BP is used to
> > > > traverse an open network where some of the intermediate nodes are
> > not fully trusted.
> > > > Like you said, it would be possible for the configuration of a node
> > > > to have a specific whitelist of which public hosts are trusted to
> forward
> > bundles.
> > > > And maybe the node policy can be nuanced as you have stated so that
> > > > if a node is the bundle destination it *must* have a
TLS-authenticated
> > Node ID.
> > > > In the end, the whole point of CL-level security is to ensure that
> > > > data/bundles are not being leaked in the clear on a single hop. You
> > > > still need to use BPSEC if the intent is to guaruantee integrity or
> > > > authenticity of the bundle itself.
> > > >
> > > >
> > > >
> > > > Because ACME [2] provides a solid infrastructure to separate the
> > > > mechanisms of how to challenge and validate a claim from what to do
> > > > with the validated claims (i.e. issue a requested certificate), if
> > > > it seems reasonable I am willing to create a draft of a new ACME
> > > > challenge type for validating a DTN Node ID using a new BP
> > > > administrative record type. This challenge type would be extremely
> > > > logically simple and could be done on its own, outside of an ACME
> server,
> > to validate ownership of a Node ID in a more "manual" way.
> > > > Doing this gives us something more concrete than a BCP explaining a
> > > > procedure.
> > >
> > > I am wary of describing this as "outside of an ACME server": the
> > > separate account-provisioning step and cryptographic means to bind an
> > > intent to authorize a given name by a given account to the actual
> > > challenge and challenge-validation steps are important parts of
> > > achieving the properties that ACME provides.
> > >
> > > >
> > > >
> > > > [1]
> > > > https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-20#section-8.8
> > > >
> > > > [2] https://tools.ietf.org/html/rfc8555#section-8
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > From: Magnus Westerlund <[e-mail]
> > > > <mailto:[e-mail]> >
> > > > Sent: Monday, June 1, 2020 09:53
> > > > To: [e-mail] <mailto:[e-mail]>  <[e-mail]
> > > > <mailto:[e-mail]> >; Brian Sipos <[e-mail]
> > > > <mailto:[e-mail]> >; [e-mail]
> > <mailto:[e-mail]>
> > > > <[e-mail] <mailto:[e-mail]> >
> > > > Cc: [e-mail] <mailto:[e-mail]>
> > > > <[e-mail] <mailto:[e-mail]> >; [e-mail]
> > > > <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]> >;
> > > > [e-mail]
> > > > <mailto:[e-mail]>
> > > > <[e-mail]
> > > > <mailto:[e-mail]> >;
> > > > [e-mail] <mailto:[e-mail]>
> > > > <[e-mail] <mailto:[e-mail]> >
> > > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I would appreciate the SEC ADs input on this.
> > > >
> > > > I think you are correct that PKI structure and how to validate IPN
> > > > and DTN URI in regards to the certificats are seperate document.
> > > >
> > > > So don't we have two different aspects here for TCPCLv4. One when it
> > > > is used as CL to reach a next hop in the routing infrastructure,
> > > > where the sending agent only need to know that it connected to the
> > > > intended next hop. The other case is when the agent uses the CL to
> > > > directly reach the peer agent with the intended BP layer destination
> > > > Node ID. Maybe I have focused to much on the later and it is only
> > > > the former that actually are needed here. Still BP routers do have
> > > > their own Node ID and thus, I guess the identification dilema for
> > > > Node IDs do remain.
> > >
> > > (I think this dilemma is at the core of my uneasiness with the draft
> > > originally proposed for IESG Evaluation.  It's not a problem that's
> > > fully solvable, though, so we'll need to clearly document what we
> > > do/don't do and move on, as was noted later in the thread.)
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Magnus Westerlund
> >
> >
> > ----------------------------------------------------------------------
> > Networks, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Torshamnsgatan 23           | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn