Re: [Sidrops] HTTPS in TALs

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

-G

On Wed, Jul 19, 2017 at 9:07 PM, Nick Hilliard <nick@foobar.org> wrote:
> Looks good to me.
>
> Nick
>
> Geoff Huston 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
>>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops