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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Mar 2017 03:04:24 -0800

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 3.2: HTTPS reference is out-of-date.

SHA-256 needs a reference.

The shepherding write up says that the schema was not validated. Why not?

---

From: Rob Austein <[email-masked]>
Date: Thu, 02 Mar 2017 08:42:12 -0500

Er, the write-up is incorrect on this point.  The schema passes
validation with trang and xmllint.

I'm not the lead author on this I-D, so this isn't one of my
automated-schema-validation-before-running-xml2rfc hacks, but I just
extracted the current schema from the -07 text and ran it through
trang and xmllint by hand, no problems reported.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 2 Mar 2017 14:06:53 +0000

Hi Rob,

> On 2 Mar 2017, at 13:42, Rob Austein <[email-masked]> wrote:
> 

Good to know! The write-up should be corrected on this point.

Thank you,
Alexey

---

From: Chris Morrow <[email-masked]>
Date: Thu, 02 Mar 2017 09:24:08 -0500

At Thu, 2 Mar 2017 14:06:53 +0000,
> Good to know! The write-up should be corrected on this point.

sorry, fixed.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 7 Mar 2017 14:38:07 +0100

Hi all,

> On 02 Mar 2017, at 12:04, Alexey Melnikov <[email-masked]> wrote:
> 

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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Mar 2017 15:15:49 +0000

Hi Tim,

On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote:
> 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.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 8 Mar 2017 10:29:09 +0100

Hi Alexey

> On 07 Mar 2017, at 16:15, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Tim,
> 

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

   Repository Server.

   validation issues found, so that an operator can investigate the

   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:

   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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 8 Mar 2017 10:01:21 +0000

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-masked]> wrote:
> 
> Hi Alexey
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 8 Mar 2017 15:10:48 +0100

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-masked]> wrote:
> 
> Hi Tim,
> (Top post)
> 
> On 8 Mar 2017, at 09:29, Tim Bruijnzeels <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Alexey
>> 
>>> On 07 Mar 2017, at 16:15, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Tim,
>>> 
>>>>> On 02 Mar 2017, at 12:04, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ <https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/>
>>>>> 
>>>>> 
>>>>> 
>>>>> <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>>.
>>>>              <http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/>
>>>>              fips-180-4.pdf>.
>>