In view of recent issues in TurkTelecom and Indosat, it seems like the simplest
reason would be to ensure that data putatively obtained from the IETF would in
fact be obtained from the IETF.
From my perspective, I would support a statement to the effect that IETF
technology should be obtainable using https or whatever else we are
recommending as "secure.” I’d also be in favor of asking IETF contributors to
obtain and use PGP keys and/or DKIM encodings to sign messages. And of asking
that IETF tools not reformat email in ways that corrupt data that has been
signed.
To that end, I could imagine a requirement for some kind of roadmap. “The tools
that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After
<date>, we require them to use Secure X, Secure Y, and Secure Z, and traffic
originated by the IETF sites shall use such protocols."
On Apr 3, 2014, at 4:24 PM, Randall Gellens
<randy(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
My reaction is also to ask "Why?" Security and privacy involve trade-offs
where various costs (including operational difficulty) are weighed against
the benefits, such as protecting information from unauthorized disclosure or
modification. So, I'd suggest that a blanket statement isn't a good idea,
but rather, a service-by-service decision should be made. For example, XMPP
and document submission may justify requiring encryption while email and
document retrieval might not.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
!!!!!CP MBI na ni deppart m'I !pleH
signature.asc
Description: Message signed with OpenPGP using GPGMail