Re: TFTP URL

--On Wednesday, 21 November, 2001 10:09 +0100 Patrik Fältström
<paf@cisco.com> wrote:

> (a) I think it is a good thing to have a URI scheme defined
> for all protocols we have in the IETF

I think we disagree about that.  I think that we should have
them only where they are demonstrably needed and, consequently,
worth whatever risks they imply.  Part of my problem is that the
existence of URIs may encourage indiscriminate use of the
protocols while, if someone has to go to a bit more effort, they
might actually _read_ the "security consideration" sections we
go to so much trouble to write.  And, in some cases, the URI
schemes considerably "dumb down" the protocols, which may not be
a good thing either (for better or worse, "dumbing down" TFTP is
not a concern).

As I have said in other contexts, I am becoming increasingly
convinced that the IETF needs to stop using the fact that we
know how to do something as an argument that we should do it.

> (b) A specification of a URI scheme need to explain when it is
> to, and more importantly, when it is not to be used
> 
> Correct me if I am wrong John, but the conclusion I see of
> this discussion is that the document is describing the general
> URI, but, doesn't describe enough in the Security
> Consideration Section why this is a bad thing to use the wrong
> way.

_If_ there is adequate justification for creating a URL for TFTP
at all (and we probably disagree about what should be considered
adequate), then, yes, I think the Security Considerations
section  of this document needs a good deal of work and that we
need to pay careful attention to the Security Considerations
section of any protocol that specifies (or is likely to use) a
configuration file that might contain a URI.

     john


> --On 01-11-21 03.45 -0500 John C Klensin <klensin@jck.com>
> wrote:
> 
>> 
>> 
>> --On Wednesday, 21 November, 2001 16:37 +0900 Martin Duerst
>> <duerst@w3.org> wrote:
>> 
>>> I don't have much to add here, except to very clearly point
>>> out that URIs are about much more than only 'just click
>>> here'.
>> 
>> Of course.  But we have claimed for years that the default
>> answer to a request for a new URL/URI type is, in the absence
>> of justification, "no" .  And the only justifications that are
>> apparent for this one are "just click here" and, more
>> importantly, "make it a bit more convenient to specify what
>> goes into a configuration file".   I don't consider either, in
>> itself, to be adequate.
>> 
>> Moreover, in most configuration file contexts with TFTP (or
>> anything else for that matter), one of the following is true:
>> 
>> (i) The config file entry is going to be a TFTP reference and
>> anything else is invalid.  In that case, use of a URI provides
>> not extra advantages other than appearing to be "modern"
>> (another reason I don't find persuasive).
>> 
>> (ii) The entry can be a general URI (or even URL), or will be
>> interpreted that way.  This strikes me as a good way to get
>> into trouble when files are executed in the background, as
>> config files usually are.  It is probably even a security
>> risk that should be documented with each impacted config
>> file.  
>> 
>> And, of course, if the first case is intended, but someone
>> does a bit of shortcut programming and says "aha, this is
>> just a URL, call the general URL processor", a really neat
>> set of exploit attempts opens up.  So, again, if this thing
>> is to go through, I suggest the security considerations
>> section be strengthened.  A lot.
>> 
>>      john
>> 
>> 
>>  
> 
> 
> 
> Patrik Fältström <paf@cisco.com>                         Cisco
> Systems Consulting Engineer
> Office of the CSO Phone: (Stockholm) +46-8-6859131
> (San Jose) +1-408-525-8509         PGP: 2DFC AAF6 16F0 F276
> 7843  2DC1 BC79 51D9 7D25 B8DC
> 
> 
>

Received on Wednesday, 21 November 2001 04:28:36 UTC