Re: [Sidrops] Adam Roach's Yes on draft-ietf-sidrops-https-tal-07: (with COMMENT)

[Adam Roach <[e-mail]>]

My apologies for the slow response here -- somehow I missed this message 
back when you sent it. Reply inline.

On 4/16/19 7:47 AM, Tim Bruijnzeels wrote:
> Hi Adam, all,
>
>> On 10 Apr 2019, at 19:21, Adam Roach via Datatracker <[e-mail]> wrote:
>>
>> Adam Roach has entered the following ballot position for
>> draft-ietf-sidrops-https-tal-07: Yes
>>
>> 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-sidrops-https-tal/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks to everyone who worked on this document.
>>
>> ---------------------------------------------------------------------------
>>
>> I find it curious and somewhat problematic that there is not a section,
>> equivalent to the existing section 4, that deals with RSYNC considerations. In
>> particular, the attack described in the first paragraph of section 4 appears
>> to be unavoidable when the TAL contains an RSYNC URI. Minimally, this document
>> should draw attention to that fact, at least in the Security Considerations
>> section. Ideally, it would deprecate -- or at least discourage -- the use of
>> RSYNC URIs for this reason.
> Good point.
>
> How about if we change the name of section 4 from "HTTPS Considerations" to "URI Scheme Considerations"
>
> And start off with:
>
> Please note that the RSYNC protocol provides neither transport security nor any means by which the Relying Party can validate that they are connected to the proper host. There it is RECOMMENDED that HTTPS is used as the preferred scheme.
>
> And change:
>     Note that a Man in the Middle (MITM) cannot produce a CA certificate
>     that would be considered valid according to the process described in
>     Section 3.  However, a MITM attack can be performed to prevent the
>     Relying Party from learning about an updated CA certificate.  Because
>     of this, Relying Parties MUST do TLS certificate and host name
>     validation when they fetch a CA certificate using an HTTPS URI on a
>     TAL.
>
> To:
>   
>     Relying Parties MUST do TLS certificate and host name validation when
>     they fetch a CA certificate using an HTTPS URI on a TAL. Note that,
>     although a Man in the Middle (MITM) cannot produce a CA certificate
>     that would be considered valid according to the process described in
>     Section 3, this attack can prevent that the Relying Party learns about
>     an updated CA certificate.


Thanks! These changes address the issue.

/a