Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT)

Tim Bruijnzeels <tim@ripe.net> Tue, 07 March 2017 14:43 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B986126D74; Tue, 7 Mar 2017 06:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAVVh4yuHfZo; Tue, 7 Mar 2017 06:42:48 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E2D12947A; Tue, 7 Mar 2017 06:38:43 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <tim@ripe.net>) id 1clFJX-0006Lb-QL; Tue, 07 Mar 2017 14:38:09 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-249.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1clFJX-0006ur-IC; Tue, 07 Mar 2017 14:38:07 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com>
Date: Tue, 7 Mar 2017 14:38:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net>
References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ------
X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e3792d7a463aa3c15896e7a9bc5b3991
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/SsywEY8wdlNciut5KFIzIfwnIt4>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org
Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 14:43:02 -0000

Hi all,

> On 02 Mar 2017, at 12:04, Alexey Melnikov <aamelnikov@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.:

   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>.