Subject: [Sidrops] HTTPS in TALs

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 19 Jul 2017 10:59:42 +0200

Dear WG,

As presented I want to propose a change to RFC7730 to move to HTTPS URIs, rather than RSYNC.

The reasons why I want this change are:
- As a TA operator I feel more confident assuring the availability of a TA certificate over HTTPS compared to RSYNC
- As an RP implementer I want to reduce the dependency on rsync in the validator. Especially if RRDP is also used, this would mean we don’t need to call rsync at all anymore.

Conventional wisdom would be to first allow HTTPS in addition to RSYNC (and make it preferred if available), then mandate it, and then deprecate RSYNC.

However, I feel that in this case it would be perfectly safe, and much simpler to go for the end-stage immediately for the following reasons:
- step 1 of allowing HTTPS already forces RP software to support HTTPS
- nothing stops us from having a mix of RFC7730 style TALs and ‘HTTPS’ TALs for a while:
— TAs can create new TALs when they are ready to publish their certificate using an HTTPS URI
— TAs can continue to have their certificate available under RSYNC for those RPs unaware of the updated TAL
— We can pursue parallel efforts (other thread) to have a way for TAs to pro-actively communicate an updated TAL to RPs
- and, of course, updating/replacing 7730 in one step rather than 3 is a lot less work

So, updating 7730 to use HTTPS this way is almost as simple as 's/rsync/https/g’, and updating the references.

In addition I would advocate an HTTPS consideration section, similar to:
https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3

Essentially, TLS certificate or host name validation issues found are worth logging about, but since the RP can verify that the retrieved TA certificate matches the “subjectPublicKeyInfo” in the TAL, and is newer than previously obtained certificate, it should be safe to process. We should probably also advocate that in cases where multiple HTTPS URIs are present, and TLS certificate or host name validation issues are found, other URIs are also followed to see if there is no newer TA certificate. This may be left to local policy, but I believe this will help against replay attacks where RPs are presented an outdated TA certificate.

So, questions to the WG:
= Can we adopt this work?
= What is the best path? Are the 7730 authors willing to update? Should I start work on a -bis?

Thanks

Tim

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Jul 2017 20:14:00 +0200

This particular author of RFC7730 is more than happy to apply s/rsync/https/g on RFC7730, but will only do so if the chairs can gather the consensus of the WG to proceed in this direction, of course

regards,

  Geoff

> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Dear WG,
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 Jul 2017 18:30:05 +0000

Hi all,

I'd like to encourage the working group to consider modernizing the file
format a bit. I'd like to see JSON or XML on anything that is structured,
and a version field somewhere.

Kind regards,

Job

On Wed, 19 Jul 2017 at 20:14, Geoff Huston <[email-masked]> wrote:

> This particular author of RFC7730 is more than happy to apply
> s/rsync/https/g on RFC7730, but will only do so if the chairs can gather
> the consensus of the WG to proceed in this direction, of course
>
> regards,
>
>   Geoff
>
>
> > - As a TA operator I feel more confident assuring the availability of a
> TA certificate over HTTPS compared to RSYNC
> > - As an RP implementer I want to reduce the dependency on rsync in the
> validator. Especially if RRDP is also used, this would mean we don’t need
> to call rsync at all anymore.
> >
> > Conventional wisdom would be to first allow HTTPS in addition to RSYNC
> (and make it preferred if available), then mandate it, and then deprecate
> RSYNC.
> >
> > However, I feel that in this case it would be perfectly safe, and much
> simpler to go for the end-stage immediately for the following reasons:
> > — We can pursue parallel efforts (other thread) to have a way for TAs to
> pro-actively communicate an updated TAL to RPs
> > So, updating 7730 to use HTTPS this way is almost as simple as
> 's/rsync/https/g’, and updating the references.
> >
> > Essentially, TLS certificate or host name validation issues found are
> worth logging about, but since the RP can verify that the retrieved TA
> certificate matches the “subjectPublicKeyInfo” in the TAL, and is newer
> than previously obtained certificate, it should be safe to process. We
> should probably also advocate that in cases where multiple HTTPS URIs are
> present, and TLS certificate or host name validation issues are found,
> other URIs are also followed to see if there is no newer TA certificate.
> This may be left to local policy, but I believe this will help against
> replay attacks where RPs are presented an outdated TA certificate.
> >
> > So, questions to the WG:

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Jul 2017 20:07:55 +0100

Looks good to me.

Nick

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Jul 2017 21:50:20 +0200

I think a simple revspin is a no brainer. I think we should go there.

-G

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 20 Jul 2017 01:44:19 +0000

Hi,

Agree to move forward.

One observation is that we should explicitly include a section on the transition from RFC7730 to 7730bis where TA operators have, for a reasonable amount of time, both HTTPS and RSYNC URIs available (even though only HTTPS will be mandatory going forward.)

Regards,
Roque

On 19/07/17 15:14, "Sidrops on behalf of Geoff Huston" <[email-masked] on behalf of [email-masked]> wrote:

    regards,
    
      Geoff

---

From: Di Ma <[email-masked]>
Date: Thu, 20 Jul 2017 11:05:38 +0200

I am in favor of this work.

And I, as an RP software implementer, agree with Roque on the way to move forward, which is to leave a reasonable amount of time, both HTTPS and RSYNC URIs available.

Di

> 在 2017年7月20日，03:44，Roque Gagliano (rogaglia) <[email-masked]> 写道：
> 
> Hi,
> 
> Agree to move forward.
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 20 Jul 2017 11:17:49 +0200

Hi Di, all,

> On 20 Jul 2017, at 11:05, Di Ma <[email-masked]> wrote:
> 

I believe this can be achieved by allowing a reasonable amount of time where both current RFC7730 style RSYNC only TALs and 7730-bis HTTPS only TALs are available.

RPs that do not support HTTPS (yet) can then use the current RFC7730 style TALs without surprising HTTPS URIs occurring
RPs that are upgraded to support HTTPS in TALs can just as easily use (multiple) HTTPS only, without the need for RSYNC fallback.

So, I believe that there is no strong operational need for having both URI types in one TAL, while it would complicate the document update cycle.

Tim

---

From: Rob Austein <[email-masked]>
Date: Sun, 23 Jul 2017 14:47:19 -0400

I think we should move from rsync to HTTPS for fetching TALs, yes, so
I think the WG should be doing something of this general nature.

How many stages...I think at this point I would be most comfortable
with making HTTPS mandatory and rsync optional.

My own RP implementation has supported both schemes for years (albeit
only on a development branch until about a year ago).  I don't know
the status of the other RP implementations, but the authors of those
can speak for themselves.

Regarding Job's request that we change format to JSON or XML or ...,
I must respectfully disagree.  The current format was deliberately
chosen to be as simple as possible, no presentation-layer-du-jour
parsing library required.  ASN.1 is enough fun for somebody who has to
implement an RP in an embedded environment, but that is required,
because all of the objects being validated are ASN.1.  Let's please
not add a requirement for another whole parser just for TALs when the
trivial line-oriented thing we have now will suffice.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 24 Jul 2017 12:39:25 +0200

> On 23 Jul 2017, at 20:47, Rob Austein <[email-masked]> wrote:
> 

At this point agreeing on the direction is the most important point to me.

> with making HTTPS mandatory and rsync optional.

That said, I can’t help myself ;)

Why? If HTTPS is mandatory to implement for both CAs and RPs, what operational concern is addressed by allowing optional rsync in the same TAL in addition?

Again, I sympathise that CAs and RPs (including ours) need to time to move, but to me it’s much simpler to address that by having RFC7730 and 7730-bis (HTTPS only) TALs defined, and agreeing on a strategy to allow the use of -bis by CAs, support them in RPs, and once the 5 RIR TAs and 3 RPs have moved, discontinuing 7730 (rsync only). Guiding this process in subsequent RFC updates seems like unnecessary overhead to me. Still, I would rather have that, and progress, if I am alone in this.. To me the end goal is what counts here.

> can speak for themselves.

We don’t yet support in production I believe, but I think we had code on a development branch when working on RRDP - in any case this will be trivial to add for us.

(And beneficial even because it will make automated scenario testing easier of our CA code publishing with our Publication Server, and RP validating and expecting specific results - without the need for rsync)

> trivial line-oriented thing we have now will suffice.

While I would have been happier with JSON or XML in the first place I don’t see a need to change the general format now.

We already know how to parse the current TALs - the only change is in the scheme used in URIs - leaving the format as-is will be least intrusive for existing deployment at this point.