Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT)
Alexey Melnikov <aamelnikov@fastmail.fm> Tue, 07 March 2017 15:16 UTC
Return-Path: <aamelnikov@fastmail.fm>
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 0A0B0129440; Tue, 7 Mar 2017 07:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=FoAjW4kC; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=D5Tm4NQR
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 lFP6e_hkWyLW; Tue, 7 Mar 2017 07:16:08 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0108126DFB; Tue, 7 Mar 2017 07:15:51 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0E3D120A7F; Tue, 7 Mar 2017 10:15:50 -0500 (EST)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 07 Mar 2017 10:15:50 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=nwx7FbiFPxSNbSWMH2/W8ox/ig k=; b=FoAjW4kCXtJvNkSJpC9s/efx5Imst40ppBHiFYDTvXHQFwtNvcMibjoj+A Wbzd4bw9y8HWW9G3SjM/jgi933RY6WZtOK14wUOrijqmKk1j9dPQW8L3Cp0fIzHY iQ5BQ9dRdceqkaaHmHgWw4r3JE1wCV1XLyWwy6FzONuHPzxiA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=nw x7FbiFPxSNbSWMH2/W8ox/igk=; b=D5Tm4NQRuwVl5wljctEJd4cqgczeFpZplv WrEXp7Qazv+ODKD3GR7uq5yF6OLD6mbfzBGo+WI6eKpDys34uHDRNWlaoH7Y7L9N V1dvSrYK1xafRCMR9RCkU+LkERzTL1abCvXFKPEVj8MAuSKeVcUuNTzLW9PTaIeL dioNosU3Q=
X-ME-Sender: <xms:pc6-WEar3h4ZqH5dOxVgYXYKexBdygl1Tqr8009qvxIAnrFpuQZZfg>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id DFCA66AC15; Tue, 7 Mar 2017 10:15:49 -0500 (EST)
Message-Id: <1488899749.1393566.903326592.39278005@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Tim Bruijnzeels <tim@ripe.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-9f47d516
Date: Tue, 07 Mar 2017 15:15:49 +0000
In-Reply-To: <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net>
References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net>
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 15:16:10 -0000
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 <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.: 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] Alexey Melnikov's Discuss on draft-ietf-si… Alexey Melnikov
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Rob Austein
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Chris Morrow
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Tim Bruijnzeels
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Tim Bruijnzeels
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [sidr] Alexey Melnikov's Discuss on draft-iet… Tim Bruijnzeels