Re: [ietf-privacy] "Opportunistic encryption" and a need for a definition

Hiya,

On 11/19/2013 09:46 AM, Stephane Bortzmeyer wrote:
> On Tue, Nov 19, 2013 at 10:39:00AM +0100,
>  Eliot Lear <lear@cisco.com> wrote 
>  a message of 55 lines which said:
> 
>> in fact there are several different forms.
> 
> I find three:
> 
> 1) Encryption without a peer-specific arrangement. This is the meaning
> used in RFC 4322. Can be safe.

So I (1) that to mean that there's a not-so-secure way to
validate that the right key for a peer is being used, in
4322 via DNS without DNSSEC. Adding DNSSEC gets you beyond
OE I'd say.

> 2) Encryption without authentication. This is the meaning used in RFC
> 5386. Safe only against a purely passive attacker.
> 
> 3) Encryption with a fallback to unencrypted mode. This is the
> Wikipedia definition. Certainly unsafe.
> 
> draft-cooper-ietf-privacy-requirements-01 mixes 1) and 2)

That's a fair comment. Since the draft is calling for a minimum
I think (2) is more appropriate for now since there will be some
places where its not feasible to get (1).

When we push out another rev, we'll make that clear, specific
text suggestions are welcome too of course.

>> As such, it's a good opportunity for an informational document.
> 
> Volunteers are welcome to start from the list above :-)

Actually, I'd like (if possible) to go a bit further than
simply definitions, I think the info document we want is
a "HOWTO pimp my protocol with OE" spec, but for that to
be done well, I think we need an author or two who's recently
e.g. implemented ECDH in protocols. I've asked someone but
they're busy, if you know someone who could do that then
either twist their arm yourself or point me at 'em. (Or if
that describes you, then either write something or get in
touch with me.) Trying to get an implementer like that does
make it a bit harder to get started, but if the resulting
RFC is to be really useful, I think it'll need to be fairly
high quality since it could end up being used in lots of
protocols, probably via ^C^V, so getting it right will be
more important than usual perhaps.

Cheers,
S.

> _______________________________________________
> ietf-privacy mailing list
> ietf-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
> 