-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Polina,
On 06/15/2013 12:35 PM, Polina Goltsman wrote: > Dear Marc, > > Thank you very much for your comments. > > On 14.06.2013 18:38, Marc Petit-Huguenin wrote: Hi Polina, > > Please find below my answers to some of your comments. Note that I am not > a co-author of the spec, so that will be just my opinion. > > On 04/22/2013 11:30 AM, Polina Goltsman wrote: >>>> Hi, >>>> >>>> I have several questions regarding certificates with multiple >>>> NodeIDs. It seems that different parts in the draft contradict each >>>> other. >>>> >>>> First, section 6.6.1 defines requirements for future overlay link >>>> protocols. I suppose, that current overlay link protocol must meet >>>> these requirements. >>>>> Endpoint authentication When a node forms an association with >>>>> another endpoint, it MUST be possible to cryptographically verify >>>>> that the endpoint has a given Node-ID. >>>> Certificates with multiple NodeIDs sometimes violate this >>>> requirement. Unless a connection was formed as a result of exchanging >>>> Attach messages, it is impossible to associate an endpoint and its >>>> NodeID, which is the case when new node connects to BootstrapPeer. As >>>> a consequence several reload requirements are hard or even impossible >>>> to implement IMHO. >>>> >>>> The first requirement is that ConnectionTable SHOULD use some >>>> indexes instead of mapping NodeIds to (D)TLS Connections. > I am not sure where in the spec you found this requirement. >> A have found this requirement in section 6.3.2.2. at the bottom of page >> 53 (-26) > >>> One possible encoding of the 16 bit integer version as an opaque >>> identifier is to encode an index into a Connection Table. >> and so on. This is not a requirement for the management of the Connection Table, just a compression algorithm to reference an entry in the Connection Table in the destination_list. > >> I am not very good at this, but as I understood one must have very good >> reasons not to implement "SHOULD". Yes, but because the entity decoding the 16 bit opaque_id is the same that encode it, it does not matter. There is no interoperability problem that can be created by following or not the SHOULD. IMO, as this cannot create any interoperability issue, the whole paragraph should have been moved to an appendix, as this is more an implementation note, than normative stuff. >>>> The second requirement is in section 6.1.2 >>>>> If a node with a certificate with multiple Node-IDs attempts to >>>>> route a message other than a Ping or Attach through a node without >>>>> performing an Attach, the receiving node MUST reject the request >>>>> with an Error_Forbidden error. The node MUST implement support for >>>>> returning responses to a Ping or Attach request made by a >>>>> joiningnode Attaching to its responsible peer. >>>> The routing decisions must be made based on ForwardingHeader alone, >>>> and a ForwardingHeader does not contain information about type of the >>>> message, being sent. So this is practically NOT implementable. > I agree that there is a layer violation here. > > But this applies only to bootstrap nodes, which anyway require special > processing on their public address, as they accept connections without > Attach. So the special code that parses the message in addition to the > header can be isolated to that special kind of nodes. >> From -base: Section 3.2.1 Client Routing > >> **Clients** may insert themselves in the overlay in two ways: > >> ... > >> (bullet 2)Establish a connection with an arbitrary peer in the overlay > >> ... > >> A **client** connected this way using a certificate with only a single >> Node-ID can proceed to use the connection without performing an Attach >> (Section 6.5.1 ). A **client** wishing to connect using this mechanism >> with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3 ) >> to probe the Node-ID of the node to which it is connected before doing >> the Attach. > > >> Do I understand this wrong, or any client can connect to any peer it >> wants, so the issue is not only with BP. My understanding of this is that an Attach is required to do that, so the special processing really applied only to bootstrap nodes. You can Attach to any node and never send an Update, relying on a stored Destination_list to be reached and the via_list to receive responses, but the initial still have to go through a bootstrap node. > >> Moreover, did I miss a requirement that forbids me to for direct >> connection (without Attach) if I know IP-Address of the Node I wish to >> connect to. (This didn't make it to the -base, did it >> ?https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html) >> <https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html%29**> My >> understanding is that you cannot directly connect to a random node. You always have to do through a bootstrap node. Note that this understanding seems to contradict 11.4. IMO the whole 11.4 should have been removed, as there is no way to be sure 100% that an IP address can be directly reached. Caching peers to serve as future bootstrap nodes would require to use a TURN server to contact them. And as you said, it increase the load on all node as they all can be bootstrap candidates. >>>> Section 3.2.1 Bullet 2 - about Clients, that connect to peers >>>>> A client connected this way using a certificate with only a single >>>>> Node-ID can proceed to use the connection without performing an >>>>> Attach (Section 6.5.1). A client wishing to connect using this >>>>> mechanism with a certificate with multiple Node-IDs can use a Ping >>>>> (Section >6.5.3) to probe the Node-ID of the node to which it is >>>>> connected before doing the Attach. >>>> As far as I understand, the procedure is as follows. The peer in >>>> the overlay, that listens on some known port, receives a connection >>>> from a client. This connection is in some unknown state because >>>> NodeId of at least one endpoint is not known. Then, the client must >>>> send a PingReq to the wildcard NodeId. It will be consumed by the >>>> peer as the next endpoint. > Not sure what you mean by next endpoint. The Ping will be answered by > this peer, returning a SecureBlock containing the Certificate of this > peer. >> Exactly this. I mean endpoint as in the "endpoint of connection or link" >>>> Once the client has learned the peer's NodeID, it may send Attach, >>>> with, as I suppose, one static candidate. The peer must somehow find >>>> out that this static candidate is the connection, that is already >>>> formed and do not try to form it again. > My understanding is that the Attach creates a new connection and that the > first one is closed. But this is underspecified so this will create an > interoperability problem. > >>>> (Moreover the Attach section doesn't state what to do if the >>>> connection is already formed. This is also essential for the topology >>>> plugin, since some node may already have an opened connection with >>>> its new neighbour (consider peer-ready update), but in that case >>>> NodeIds are known and connection table can be searched). >>>> >>>> In my opinion, both client and peer could learn each other's NodeIDs >>>> from the Ping. Both PingReq and PingAns are signed and thus uniquely >>>> identify its senders. Since the connection to the client is in some >>>> unknown state and the destination was wildcard NodeID, the peer can >>>> assume that the sender of this message is another endpoint of this >>>> connection. The peer can also compare the client's certificate with >>>> the one, used to form TLS association. >>>> >>>> >>>> >>>> Another question, that I have, is shared-secret admission schemes for >>>> TLS. The TLS-PSK RFC states, that in case of TLS-PSK certificate >>>> exchange is optional. It is unclear from the RFC, that PSK ciphers >>>> with certificate exchange must be selected. > I think it is clearly stated in 1.3 that certificate must be used with > TLS-PSK in the context of RELOAD: > > "This feature is used together with certificate-based access control, not > as a replacement for it." > >> The point is that IMHO it(together with 3.2.1) should be specified >> somewhere after section 5. Yes, the whole shared-secret/TLS-PSK/TLS-SRP/self-signed-certificate is underspecified. A good candidate for an Internet-Draft. >>>> It is also unclear, what should be sent in TLS-PSK identity field - >>>> username, NodeID, both or nothing. As of TLS-SRP RFC the client >>>> certificate cannot be requested. > The identity field is used to select a specific key, when there is a > choice between different keys. In the case of RELOAD I suppose that having > multiple keys does not make sense so that field (and so the > ServerKeyEchange record) should be omitted. >> Thank you very much for the explanation. Do you think it should be >> specified, that this key SHOULD be omitted? >>>> I also can imagine two possible solutions to the first problem. >>>> >>>> Solution 1(undesirable): Have a specified way of finding out peer's >>>> identity. If one of the certificates had multiple NodeIds, the first >>>> message, that is sent over this connection must identified both >>>> peers. This can be Ping, Attach or some dedicated "HelloReq" and it >>>> works as described above. After this exchange both peers must update >>>> their connection tables with NodeIDs of the endpoints. >>>> >>>> This solution is undesirable, since it increases message load on >>>> bootstrap nodes. > AFAIK, this is how things are suppose to work in RELOAD. Note that the > increased load is only when joining the overlay, so that seems like normal > workload to me. > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html >> 1) This would increase load on the Bootstrap Peer, which IMHO is not >> desirable. 2) From your message: * *>Because there is no Attach, the peer >> has to spy on the first message sent by the > >> client to extract the Node-ID from the SignerIdentity and "label" the >> newly created connection in the connection table. > > >> Well, it was not that obvious to me. Was there a reason why it didn't >> make it to the -base? None that I can think of. Again a good candidate for an Internet-Draft. > >> I believe it is relatively hard to spy on the messages, that are routed >> through, since they can be fragmented. So IMHO the first message should >> be destined to the connection endpoint. >>>> Solution 2: Use TLS Extension to exchange not only the certificates, >>>> but also NodeID (in some form, e.g. the cert_hash_node_id form) >>>> during the TLS connection. > Yes, I proposed something like this back in 2011: > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html > > That was not the solution selected by the authors. > >>>> The extension can use SupplementaryData [RFC 4680 >>>> <http://tools.ietf.org/html/rfc4680>] to exchange the actual NodeID. >>>> For example: struct { SupplementalDataType supp_data_type; uint16 >>>> supp_data_length; select(SupplementalDataType) { case >>>> reload_signer_identity: SignerIdentity } } SupplementalDataEntry; >>>> >>>> The 2 extensions, that look most suitable are: 1. user-mapping [RFC >>>> 4681<http://tools.ietf.org/html/rfc4681>]. The information, that is >>>> sent, is exactly what is needed,but the RFC defines only client's >>>> authentication, not the server's. 2. serverautz/clientauthz [RFC >>>> 5878 <http://tools.ietf.org/html/rfc5878>]. This RFC is not >>>> standard. >>>> >>>> I also want to propose more precise way for configuring TLS >>>> connection, by using a dedicated section and overlay-config for >>>> configuring underlay link layer for reload. For example, for TLS this >>>> would be: <tls:auth> normal/PSK/SRP</tls:auth> >>>> <tls:multiple-node-id-cerificates-allowed> true/false <tls:...> >>>> <tls:shared-secret-scheme>...</..> >>>> <tls:allowed-cipher-suites>...</...> > I would suggest to write an I-D about this. > - -- Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRvdm4AAoJECnERZXWan7E2t0P/3oMLqD3lWw6f4gLMN/vf2hI qSTzKHnumRofBEgaYSeo7cqIH2RXEmDpI5b0wXnCPYsorLJp73nZD8esEAq2csom kd0xkXYUVDV7V/xNVB82ZhWhD0PJylJhunnLUcwmOhmaDzP2IqXkunfz+y0dvCBT zEGN53TfOF5sjJ/GdtMKZWoYpyfIEZ6aVDMVyuCmGvvn8Yaz15RjNFnpd8zgqC0P xdP8KVSYUE5FZuPe5nTKnRIT12wjMbauuVw+awuSsBr9bfkwaLHvqGxDv/2TR2YI 2yunV253hmIzdeqQziHsvcoShYjKN0VQ3An2X69BIi3aF7w7DpkvSdEoYVrnP+G1 Dmy/9srdbhDagPAgJ4cTOgNde2jjODMTyL/VlnX+GGH8Ui48DHPK55My5XS7l3wf H/1iO79JSB2XBDbicoXWUl51rdNqPX4v/cbl/A1bofAtUVXVLBSLSgnESBdpuSkI myjGuf2gyFUnBuURlfHy7Ni1ELecscbKZSJz2yfDpwKyJEKHkmsnLBxJmZG4/Alx PLRGUybgGoHguhxMQH886FOsGKQW5CivYKEjvOJEifm+yUuykfArJGc5pbfBBEFh RL0L6huqUkhdvLLzXcYc7bmKyyEkucS0fkpbPcw6WVkrJHtY6b3xvH7jYG2JldTM y1XU3AkmhfTNVQajv1wy =lF1v -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
