Re: [Sidrops] HTTPS in TALs

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 <gih@apnic.net> 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
>
>
> > On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels <tim@ripe.net> wrote:
> >
> > 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
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>