RE: Call for Community Feedback: Retiring IETF FTP Service

[[e-mail]]

> Hi Ned!

> Thanks for the feedback.

> > -----Original Message-----
> > From: ietf <[e-mail]> On Behalf Of
> > [e-mail]
> > Sent: Tuesday, November 17, 2020 9:02 AM
> > To: [e-mail]
> > Cc: Keith Moore <[e-mail]>
> > Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
> >
> > The discussion of FTP service retirement has actually been surprisinginly
> > informative. Things I've learned include:
> >
> > (1) The IETF no longer provides HTTP access, leaving FTP as the only
> >     access mechanism that doesn't require a crypto layer. With FTP gone,
> >     crypto becomes a requirement for access.

> Could you help me better understand which way your concern leans.  Let's
> abstract away HTTP and FTP, and just consider a communications channel.  Do you
> have a use case where access to IETF artifacts need to happen over unencrypted
> channels (i.e., getting the same artifacts over an encrypted channels breaks
> the use case)? 

For myself, I routinely use devices that are incapable of supporting a crypto
stack that would work with an IETF HTTPS server. I haven't had the need to
access IETF resources recently from such hardware, which is why I hadn't
noticed this change. But that's happenstance, nothing more.

However, the case that worries me much more is how this may affect access from
places where crypto use is problematic.

> Put via analogy, if you always get something via postcard (in the clear), but
> got it in an envelope (encrypted) instead, it break something.  Or are you
> stating a philosophical position on not providing channel security?

I'm well aware of Zimmerman's postcard/letter analogy. I'm also aware of the
responses to that analogy that pointed out that things are nowhere near
as simple as the analogy would have you believe.

				Ned