Re: [Sidrops] HTTPS in TALs

Hi Di, all,

> On 20 Jul 2017, at 11:05, Di Ma <madihello@icloud.com> wrote:
> 
> 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.

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

> 
> Di
> 
> 
>> 在 2017年7月20日，03:44，Roque Gagliano (rogaglia) <rogaglia@cisco.com> 写道：
>> 
>> 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" <sidrops-bounces@ietf.org on behalf of 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
>> 
>> 
>> _______________________________________________
>> 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