Re: [secdir] Secdir last call review of draft-ietf-add-svcb-dns-06

[Ben Schwartz <[e-mail]>]

On Tue, Jul 12, 2022, 12:52 AM Joseph Salowey <[e-mail]> wrote:

> Thanks for the quick reply, comments below:
>
> On Sat, Jul 9, 2022 at 5:33 AM Ben Schwartz <[e-mail]> wrote:
>
>> Hi Joe,
>>
>> On Fri, Jul 8, 2022 at 8:05 PM Joseph Salowey via Datatracker <
>> [e-mail]> wrote:
>>
>>> - Section 8.1.2 - good description of this problem, it seems like some
>>> of this
>>> should have been discussed in the doh document, but I couldn't find
>>> any.  If
>>> there is relevant considerations in the doh document then you should
>>> reference
>>> them here.
>>
>>
>> This topic is not addressed in RFC 8484 because that standard assumes
>> that the URI template is configured from a single source, so all its
>> components are equally authentic.  The strange thing here is that the
>> hostname comes via a (unspecified) trusted channel, but the port and path
>> do not.
>>
>>
>
> [Joe]  I see, so this adds some attack vector that was not anticipated in
> 8484
>
>
>>   It seems that the recommendation "To mitigate redirection attacks,
>>> a client of this SVCB mapping MUST NOT identify or authenticate itself
>>> when
>>> performing DNS queries, except to servers that it specifically knows are
>>> not
>>> vulnerable to such attacks." would be difficult to implement since its
>>> not
>>> clear how the client gets this information and really should be a
>>> consideration
>>> for the server implementations/deployments that require authentication.
>>
>>
>> How about "... except under private arrangement with a server operator
>> who has made sure that there are no such vulnerable services on $HOSTNAME"?
>>
>> [Joe] Could we say something like "the server operator should make sure
> that there are no such vulnerable services on $HOSTNAME before publishing
> an SVCB mapping"
>

It's not clear to me that this would help, because this attacker can forge
a SVCB record even for origins that don't publish their own record.  In the
extreme case, the origin might not operate a DNS service at all!

It seems the server should really take steps to prevent this if possible.
>

I can't think of a way to do this without adding a new requirement to all
DNS servers that are identified by a hostname.  As a practical matter I
suppose that would be fine, but in principle it seems like poor form to add
requirements to existing deployed systems.

  Having the client also verify this to the best of their ability is also a
> good idea.
>
>
>
>>   I'm
>>> not really sure what to do about this except as a consideration for a
>>> revision
>>> of DoH.
>>>
>>
>> I don't think RFC 8484 has a problem of this kind, because an adversary
>> cannot alter any portion of the URI template (unless it controls the whole
>> template).  (There is still the ALPACA attack, but that is not specific to
>> DoH.)
>>
> [Joe] yea, thanks for clarifying
>