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 <aamelni...@fastmail.fm> 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. > 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
