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

[Joseph Salowey <[e-mail]>]

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 seems the server should really take steps to prevent
this if possible.  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