> Hi Ned! > Thanks for the feedback. > > -----Original Message----- > > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of > > ned+ietf@xxxxxxxxxxxxxxxxx > > Sent: Tuesday, November 17, 2020 9:02 AM > > To: ietf@xxxxxxxx > > Cc: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > > 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
