Hi Alexey, Thanks, I am about to send an update to my co-authors so that they can also review, and upload it this Friday.
Tim > On 08 Mar 2017, at 11:01, Alexey Melnikov <[email protected]> wrote: > > Hi Tim, > (Top post) > > I think your latest suggested text is good enough, so polishing it more is > not going to improve the document in a significant way. So please post a new > version with it. > > Thank you, > Alexey > > On 8 Mar 2017, at 09:29, Tim Bruijnzeels <[email protected] > <mailto:[email protected]>> wrote: > >> Hi Alexey >> >>> On 07 Mar 2017, at 16:15, Alexey Melnikov <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Tim, >>> >>> On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote: >>>> Hi all, >>>> >>>>> On 02 Mar 2017, at 12:04, Alexey Melnikov <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Alexey Melnikov has entered the following ballot position for >>>>> draft-ietf-sidr-delta-protocol-07: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> <https://www.ietf.org/iesg/statement/discuss-criteria.html> >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >>>>> <https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I would be happy to ballot Yes on this document, as it is well written >>>>> and is a useful piece of work. However I have one issue (and a few minor >>>>> comments) that I would like to DISCUSS before doing so: >>>>> >>>>> In Section 5.3 the document says: >>>>> >>>>> It is RECOMMENDED that Relying Parties and Publication Servers >>>>> follow >>>>> the Best Current Practices outlined in [RFC7525] on the use of HTTP >>>>> over TLS (HTTPS) [RFC2818]. >>>>> >>>>> RFC 7525 is referencing RFC 6125 for server hostname validation. >>>>> Unfortunately this is not detailed enough to perform hostname validation, >>>>> because reference to RFC 6125 requires specifying answers to every >>>>> question in section 3 of RFC 6125. (And there is no generic RFC that >>>>> specifies how this is done for protocols using HTTP.) One example of how >>>>> this might look like is in Section 9.2 of >>>>> <https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/?include_text=1 >>>>> >>>>> <https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/?include_text=1>>. >>>>> For your convenience the relevant text is pasted below: >>>>> >>>>> Routers MUST also verify the cache's TLS server certificate, using >>>>> subjectAltName dNSName identities as described in [RFC6125], to >>>>> avoid >>>>> man-in-the-middle attacks. The rules and guidelines defined in >>>>> [RFC6125] apply here, with the following considerations: >>>>> >>>>> Support for DNS-ID identifier type (that is, the dNSName identity >>>>> in the subjectAltName extension) is REQUIRED in rpki-rtr server >>>>> and client implementations which use TLS. Certification >>>>> authorities which issue rpki-rtr server certificates MUST support >>>>> the DNS-ID identifier type, and the DNS-ID identifier type MUST >>>>> be >>>>> present in rpki-rtr server certificates. >>>>> >>>>> DNS names in rpki-rtr server certificates SHOULD NOT contain the >>>>> wildcard character "*". >>>>> >>>>> rpki-rtr implementations which use TLS MUST NOT use CN-ID >>>>> identifiers; a CN field may be present in the server >>>>> certificate's >>>>> subject name, but MUST NOT be used for authentication within the >>>>> rules described in [RFC6125]. >>>>> >>>>> The only thing missing from the above is explicit mentioning that SRV-ID >>>>> and URI-ID are not used. (I think the same should apply to your >>>>> document.) >>>> >>>> Considering that we also say: >>>> >>>> Relying Party tools SHOULD log any TLS certificate or host name >>>> validation issues thus found, so that an operator can investigate the >>>> cause. However, such validation issues are often due to >>>> configuration errors, or a lack of a common TLS trust anchor. In >>>> these cases it is better if the Relying Party retrieves the signed >>>> RPKI data regardless, and performs validation on it. Therefore >>>> Relying Party MUST continue to retrieve the data in case of errors. >>>> The Relying Party MAY choose to log encountered issues only when >>>> fetching the notification update file, but not when it subsequently >>>> fetches snapshot or delta files from the same host. Furthermore the >>>> Relying Party MAY provide a way for operators to accept untrusted >>>> connections for a given host, after the cause has been identified. >>>> >>>> >>>> And because in practice Relying Party software will use standard software >>>> libraries to do retrieval and verification, and it may be hard or even >>>> impossible to configure these libraries to do the verification as >>>> described.. would you agree with the following? Essentially taking your >>>> suggested lead, but never exceeding "SHOULD" in the "how" of the TLS >>>> certificate and host name validation that itself is a SHOULD, i.e.: >>> >>> I think it would be clearer to say that *if* validation is done, it will >>> use the following MUST/MUST NOTs. (And if validation fails, you log as >>> you recommend elsewhere.) Otherwise it would not be very clear when it >>> is Ok to violate various SHOULD/SHOULD NOTs. >> >> I see your point regarding clarity, but my main point is that I believe it >> would be overkill to have MUSTs. It may not be possible to enforce this >> behaviour in standard libraries of the language of choice for Relying Party >> implementations (currently Java (RIPE NCC), Python (rcynic) and C I believe >> for RIPSTR). And since we have RPKI object security I don't believe it would >> be a big issue if for example a wildcard certificate is used. >> >> I really do not want to have to implement our own https client library for >> this. It would require a lot of work and maintenance, and on the whole it >> would make our implementation brittle. I want to be able to use one of the >> widely used and tested standard libraries for this, even if they violate a >> SHOULD. Of course I am willing to see whether we can tweak behaviour of said >> libraries, but again this may not possible. >> >> If you agree, would it help if we moved the text around a bit (so that the >> security motivation comes first) and add this explanation explicitly at the >> end: >> >> 4.3. HTTPS considerations >> >> Note that a Man-in-the-Middle (MITM) cannot produce validly signed >> RPKI data, but can perform withhold or replay attacks targeting an >> Relying Party, and keep the Relying Party from learning about changes >> in the RPKI. Because of this Relying Parties SHOULD do TLS >> certificate and host name validation when they fetch from an RRDP >> Repository Server. >> >> Relying Party tools SHOULD log any TLS certificate or host name >> validation issues found, so that an operator can investigate the >> cause. However, such validation issues are often due to >> configuration errors, or a lack of a common TLS trust anchor. In >> these cases it is better if the Relying Party retrieves the signed >> RPKI data regardless, and performs validation on it. Therefore >> Relying Party MUST continue to retrieve the data in case of errors. >> The Relying Party MAY choose to log encountered issues only when >> fetching the notification update file, but not when it subsequently >> fetches snapshot or delta files from the same host. Furthermore the >> Relying Party MAY provide a way for operators to accept untrusted >> connections for a given host, after the cause has been identified. >> >> It is RECOMMENDED that Relying Parties and Repository Servers follow >> the Best Current Practices outlined in [RFC7525] on the use of HTTP >> over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS >> certificate and host name validation using subjectAltName dNSName >> identities as described in [RFC6125]. The rules and guidelines >> defined in [RFC6125] apply here, with the following considerations: >> >> o Relying Parties and Repository Servers SHOULD support the DNS-ID >> identifier type. The DNS-ID identifier type SHOULD be present in >> Repository Server certificates. >> >> o DNS names in Repository Server certificates SHOULD NOT contain the >> wildcard character "*". >> >> o A CN field may be present in Repository Server certificates's >> subject name, but SHOULD NOT be used for authentication within the >> rules described in [RFC6125]. >> >> o This protocol does not require the use of SRV-IDs. >> >> o This protocol does not require the use of URI-IDs. >> >> Note however that this validation is done on a best effort basis, and >> serves to highlight potential issues, but RPKI object security does >> not depend on this. Therefore Relying Parties MAY deviate from the >> validation steps listed above, in particular in case standard widely >> used software libraries in the language of the Relying Party software >> implementation do not support and/or cannot be configured to function >> this way. >> >> >> >> >> >> >> >> >> Thanks >> Tim >> >> >> >>> >>>> Note that a Man-in-the-Middle (MITM) cannot produce validly signed >>>> RPKI data, but can perform withhold or replay attacks targeting an >>>> Relying Party, and keep the Relying Party from learning about changes >>>> in the RPKI. Because of this Relying Parties SHOULD do TLS >>>> certificate and host name validation when they fetch from an RRDP >>>> Repository Server, using subjectAltName dNSName identities as >>>> described in [RFC6125]. The rules and guidelines defined in >>>> [RFC6125] apply here, with the following considerations: >>>> >>>> o Relying Parties and Repository Servers SHOULD support the DNS-ID >>>> identifier type. The DNS-ID identifier type SHOULD be present in >>>> Repository Server certificates. >>>> >>>> o DNS names in Repository Server certificates SHOULD NOT contain the >>>> wildcard character "*". >>>> >>>> o A CN field may be present in Repository Server certificates's >>>> subject name, but SHOULD NOT be used for authentication within the >>>> rules described in [RFC6125]. >>>> >>>> o This protocol does not require the use of SRV-IDs. >>>> >>>> o This protocol does not require the use of URI-IDs. >>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> In 3.2: HTTPS reference is out-of-date. >>>> >>>> updated to RFC7230 >>>> >>>>> SHA-256 needs a reference. >>>> >>>> ok, added a normative reference (same as in the publication protocol >>>> document): >>>> >>>> [SHS] National Institute of Standards and Technology, "Secure >>>> Hash Standard", March 2012, >>>> <http://csrc.nist.gov/publications/fips/fips180-4/ >>>> <http://csrc.nist.gov/publications/fips/fips180-4/> >>>> fips-180-4.pdf>. >>
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
