Re: Security for various IETF services

On Apr 3, 2014, at 5:21 PM, <l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk> 
<l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk> wrote:

> "It would be good to see the excellent work of Dukhovni and Parsons extended
> to include authentication of sending servers (clients) to support federation. 
> "
>
> Why?
In order to support data authentication.

> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Douglas Otis 
> [doug(_dot_)mtview(_at_)gmail(_dot_)com]
> Sent: 04 April 2014 01:13
> To: Fred Baker (fred)
> Cc: Randall Gellens; ietf(_at_)ietf(_dot_)org
> Subject: Re: Security for various IETF services
>
> On Apr 3, 2014, at 4:40 PM, Fred Baker (fred) <fred(_at_)cisco(_dot_)com> 
> wrote:
>
> > 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."
> Dear Fred,
>
> XMPP provides an interesting feature called server federation.  It would be 
> good to see the excellent work of Dukhovni and Parsons extended to include 
> authentication of sending servers (clients) to support federation.  This is 
> something TLS supports but is rarely used.  Such a feature could 
> significantly improve overall security especially in the wake of RTF messages 
> exposing users to remote code execution.
>
> DKIM only covers message fragments and is unrelated to the actual sender by 
> design.  A malicious link might be found in the Subject line that can be 
> followed with user clicks which may not have been signed or users might see 
> prepended From header fields which don't impact DKIM signature validity.
>
> Regards,
> Douglas Otis
        • Make things as simple as possible, but not simpler.
Albert Einstein

signature.asc
Description: Message signed with OpenPGP using GPGMail