Be liberal in what you accept? (was: Re: Last call comments: draft-farre

Hi,

> > And to think that less than 9 years ago, RFC 4041 was considered an
> > April Fool's RFC.
> >
> > Yoav
> Its a new normal, I suppose. RFC2821 once believed that "an arrogant
> user" was a small email problem:
>
>    7.1.  Mail Security and Spoofing
>
>    This specification does not further address the authentication issues
>    associated with SMTP other than to advocate that useful functionality
>    not be disabled in the hope of providing some small margin of
>    protection against an ignorant user who is trying to fake mail.
>
> Its update, RFC5321, still believes its a small problem but the user is
> no longer arrogant:
>
>    This specification does not further address the authentication issues
>    associated with SMTP other than to advocate that useful functionality
>    not be disabled in the hope of providing some small margin of
>    protection against a user who is trying to fake mail.
>
> We understand why it was done, but really, how silly was all that to
> begin with!? This (spoofing potential) was a known issue since RFC821
> and it predated with other mail networking protocols was well!
>
> The mindset does need to change.
The mindset with IETF protocols has always been "be liberal in what you
accept". While a great many of us probably still subscribe to that,
changing that mindset towards: "Be picky in what you accept" is possibly
a better boilerplate to follow, at least in some/many protocols.

As with mail, the liberal acceptance has /technically/ served very well;
emails can be delivered even if they are malformed, don't observe all
protocol functions, opt-out of any kind of step-up functionality (like
auth) etc. The problem is: we don't actually *want* those mails to be
delivered. A "picky" reception of discarding everything that is not
totally well-formed is a much healthier approach - even if it
technically makes for a higher percentage of "failed" communication. It
is the de-facto standard response of mailhubs anyway; pickiness is a
healthy defense, and thus has been deployed to overcome problems in
protocols which face large-scale abuse.

I believe that whenever there is leeway for someone to tamper with a
protocol and get away with it, it will be done so long as there's an
incentive to. Protocol options which are "reserved-zero" but mirrored in
responses can do wonders for fingerprinting and tracking - many more
"attack" vectors are possible. nmap's OS fingerprinting shows what can
be done.

If I were to apply "be liberal in what you accept" to normal
programming, I would soon feel a strong pain in the behind from people
who'd remind me how stupid that is. I guess every developer knows the
mantra that all input that comes in from external needs to be checked
and validated in every possible respect and rejected or mangled if
malformed. This comes from learning over the decades that every lapse in
this regime *will* (not just "could possibly be") exploited if there's
something to gain for an outside attacker.

So, if software devs have learnt that lesson, and have established a
mindset of requiring strict conformance, shouldn't the protocol
designer's mindset follow?

I realise that this makes interop with future revisions of a protocol
much harder - but explicit version negotiation could do its share here.

Is "Be conservative in what you accept, and conservative in what you
send" maybe more appropriate these days?

Greetings,

Stefan Winter

> Of course, the dilemma is how does the IETF community get involved in
> the growth of applications increasing leverage data that was once
> considered private or out of bounds for transmission?  How does it
> provide its input?
>
> Good example, did Apple open a can of worms, "Pandora's Box" with its
> iPhone 5S "Touch ID" technology?   Does this introduce all sorts of
> future pervasive privacy, security, monitoring, tracking, identify
> theft, etc, problems at all levels?  The BI value of this will be
> tremendous, but commercially and for national security.  This automation
> in user identification will be leverage, no doubt, MBA 101. Bank it. 
> Consider, can the government issue a court order to obtain the database
> of the billions of Touch ID fingerprint recordings in the name of
> security, searching for person of interest Apple Network of users? 
> Surely, this issue will be before us one day.
>
> I'm just winging it, perhaps an IETF security-based I-D that suggest
> what kinds of data MUST|SHOULD|MAY NOT collected, stored nor transmitted
> over the internet?  Already done?
>
> Anyway, I don't think every author, developer can muster all system
> level things that can be considered. This is why we do need the
> "Internet/IETF Elders" to be involved in the ethical and moral reviews
> of these super fast tracked documents, and mind you, now increasingly
> proposed as a "Standard" as opposed as just informational, new documents
> to see if the docs themselves are not ultimately April's fools jokes.
>
> It probably will not change much, but it will at least make people
> (future developers) think, a few times, about what they are doing.
> Perhaps it will just slow it down.  I'm sure many of us has gone thru
> this in the past where we could of been billionaires if we just were not
> so god darn ethical with user private data. We didn't expose it, not
> because we know it was not possible, but it was just wrong to do so.
>
> Thanks

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

0x8A39DC66.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature