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]> wrote: > > Hi Alexey > >> On 07 Mar 2017, at 16:15, Alexey Melnikov <[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]> 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 >>>> 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/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> 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>. >>>> 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/ >>> fips-180-4.pdf>. >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
