headers
Bill Davidsen | 4 Aug 1998 22:31
Picon
Favicon

Re: signing headers

Brad Templeton <brad <at> templetons.com> wrote:

> On Mon, Aug 03, 1998 at 02:18:26PM -0400, Bill Davidsen wrote:
> > Brad Templeton <brad <at> templetons.com> wrote:
> > We add something like that, because we find it easier than trying to
> > look up the ID from the posting host. I'm not sure it's a replacement
> > for the posting host and *verified* time, since we sometimes have to be
> > able to generate more detailed inforation than just what id was used.
> 
> But how far do you go?  You want to put the time in there too?

With posting-host and a valid time we can use radius logs to verify a
connect, and generate a called phone number from that information.
>From that a phone company can generate a calling number, even if it's on
a POP without caller-id.

And people with subpoenas have been known to ask for information like that.

> Though with 95% of ISP postings, the IP address of the poster reveals
> nothing, simply that they were at one of the ISP's dialups.

See above.

> > So in addition to "From:" the spammers will forge "Path:" too? A whole
> > new header which doesn't have a history of being passed on if present is
> > almost certainly going to be more useful.
> 
> The spammer can't forge the path.  The injector puts the identity information,
> and the injection site-id, into the path.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brad Templeton | 4 Aug 1998 23:05
Picon

Re: signing headers

On Tue, Aug 04, 1998 at 04:31:41PM -0400, Bill Davidsen wrote:
> Brad Templeton <brad <at> templetons.com> wrote:
> With posting-host and a valid time we can use radius logs to verify a
> connect, and generate a called phone number from that information.
> >From that a phone company can generate a calling number, even if it's on
> a POP without caller-id.

Oh, I agree, you should log as much information as you want, *locally*,
about articles posted on your machine.  IP address.  Identd.  Time.
Terminal server diagnostics.  Copy of "ps."  Whatever you want to log.

It's only per message posted on your machine, so the size is not a major
concern.

The question is, how much information that is not of relevance to reading
and feeding should be put in the article, to be copied 1 million times?
It has been suggested that some basics should be included, such as the
connecting IP address, possibly a "login token" with login authentication info.
Some have suggested this login-token be obfuscated so as not to interfere
with poster privacy.     Some feel the goal of the token is the reverse, to
allow external admins to get extra details on the user so they can take
action against the user without the involvement of the administrators of
the injector.

These are contradictory goals, though each have their merits?

Actually, the only thing I can think of that really needs to be in the
article might be an injector software version code, so people can track
software popularity and the source of bugs.   Though you could solve that
problem if all NNTP based injectors printed their software name and version
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brad Templeton | 5 Aug 1998 07:49
Picon

Announcing USECURE Usenet-security subgroup mailing list

Many have indicated that they would prefer if authentication and security
discussions were broken off into an independent list and possibly a
working subgroup.

As such I have created the USECURE mailing list (U-Secure or USE-CURE, take
your pick!)

To subscribe, mail to usecure-request <at> templetons.com with "subscribe"
in the *body* of the message.   ****I have set the Reply-to on this message
to be the subscription address to make things easy. ****

Or just mail the list, usecure <at> templetons.com, and it will auto-subscribe.

(I have not put it into spam protection mode as the list is not advertised
to the public.)

Kent Landfield has volunteered to support a web archive for this list
as well at www.landfield.com.   (Once he subscribes an archiver to it.)

This working group is to discuss issues of security and authentication
that have not already come to consensus in the main group.  (Ie. just
about everything but Path)

This issue, as we all know, is to many of us one of the most important, and
as as result, one of the most contentious.

See you on the usecure mailing list.
Permalink | Reply | 6 comments |
headers
Charles Lindsey | 5 Aug 1998 11:00
Picon
Picon

Re: Rogue cancels, hipcrime etc.

In <19980803202636.45728 <at> main.templetons.com> Brad Templeton <brad <at> templetons.com> writes:

>General feeling is that the cancel lock system must not be implemented
>without at least a PK signed 3rd party cancel system.  Otherwise the main
>people who will use cancel locks will be spammers.  In fact, at first
>it will be a good way to spot spammers!

I don't think we have yet agreed that, though the idea does have merit.

>So the choices are:
>	
>	b) Spend another month to design a general system that solves our
>	   known problems today, and does its best to be extensible to
>	   deal with future problems.

It will take more than a month to design a _general_ system (and anything
less than _general_ is no use). But we should be getting on with the
business of designing it anyway (see my proposals for canonicalization,
for example).

>The new software will not just check, but refuse to propagate old cancels.

I would hope not. We have been fighting for years against relays that make
arbitrary decision that "seem to them to be the right thing". Of course a
relayer can, as a matter of local policy, decide to not propagate whatever
it likes, but our draft must be clear that normal behaviour is to pass
everything, unmunged.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Lindsey | 4 Aug 1998 13:07
Picon
Picon

Re: signing headers

In <19980803131033.12149 <at> main.templetons.com> Brad Templeton <brad <at> templetons.com> writes:

>On Mon, Aug 03, 1998 at 04:48:01PM +0100, Clive D.W. Feather wrote:
>> 
>> Why wouldn't it say: "signature confirmed, some headers unsigned" ?

>It might, but since you expect that to be the case 99% of the time, this
>will not have any meaning.  An alarm bell that goes off every day is
>quickly ignored -- 4th law of security.

Yes, but what a sensible system should say is
	"Signature confirmed: (From and Date not signed)
OTOH, it should not bother to report things that regularly go unsigned,
such as Lines: .

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl <at> clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Erland Sommarskog | 3 Aug 1998 01:28
Picon
Picon

Re: The Gordian Knot Faction


Henry Spencer <henry <at> spsystems.net> writes:
> I think it is important to note here that Erland is slightly misrepresented
> the opinions of the Gordian Knot Faction. :-)
>
> We are not saying "do cancel locks and postpone article signing".  We are
> saying that it's time to postpone BOTH in the interest of getting some
> progress on the base RFC.
>
> We do NOT have rough consensus on EITHER SCHEME.
>
> We do NOT have working code for EITHER SCHEME.

I think I can side with Henry in sake of unity in the faction. :-)

Brad asked what the alternative was. Well, the alternative is simple.
Get the RFC out of the door, or least proceed with the rest of the
work with it. In the meanwhile work with the authentication and
signing stuff and come back with a working proof-of-concept. If
the RFC is still not finalized by then - God knows that there are
other controversial points - and there is a consensus on what you
present then, bring it in. Fat chance.

The issue seems to be so complex, that it seems likely to be another
RFC. If we are trying to bring it into this RFC, it might kill every-
thing - including my raison d'être for being on this list: 8bit,
in headers, bodies and newsgroup names.

Nevertheless, there is one point where I disagree with Henry:
> To: Brad Templeton <brad <at> templetons.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Babel | 4 Aug 1998 11:08
Picon

Re: Third party cancels

Brad Templeton wrote:

> Clive Feather wrote:
>
>> Who issues the certificate ? How do you
>> define "unanimous trust of the newsgroup" ?
>
> The same way moderators win the
> unanimous trust of the newsgroup.

They don't. That's why "Approved:" should be considered
nothing more than a recommendation. If you enjoy reading
articles "approved" by a particular person, give them
a high score; if you don't, ignore them and pick a
different "moderator" for that group on your machine.
Permalink | Reply | 3 comments |
headers
Clive D.W. Feather | 2 Aug 1998 09:46

Re: signing headers

Brad Templeton said:
> A good chunk only add path and NNTP-Posting-Host, which I hope they
> will move to the final component of the path line or their own log files.
> Or to C- headers for their own purposes.  Am I the only one who thinks it
> is odd for injectors etc. to store their own local diagnostic information
> in 300,000 copies around the net rather than once on their own system?

What this allows is for others to do abuse tracking of material from their
site. That is a form of decentralisation, and a good thing.

--

-- 
Clive D.W. Feather       | Work: <clive <at> linx.org>   | Tel: +44 1733 705000
Regulation Officer       |   or: <clive <at> demon.net>  |  or: +44 973 377646
London Internet Exchange | Home: <clive <at> davros.org> | Fax: +44 1733 353929
(on secondment from Demon Internet)
Permalink | Reply | 12 comments |
headers
Charles Lindsey | 4 Aug 1998 12:04
Picon
Picon

Re: signing headers

In <8790l5q2kb.fsf <at> erlenstar.demon.co.uk> Andrew Gierth <andrew <at> erlenstar.demon.co.uk> writes:

>Unfortunately pgpmoose doesn't directly cope with replay attacks (it
>does not sign the Date header).

Ughh! Then the message-id is all you have got. Sometimes you can extract a
date from that - sometimes you can't.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl <at> clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 2 Aug 1998 10:23

Re: FAQs

Brad Templeton said:
>> Details of design aren't relevant at this point. My point is that there
>> is no *one* FAQ for this group, but several of equal status (including
>> "the FAQ").
> 
> Ok, so how would you propose designing a system to handle this concept.

Off the top of my head, you could allow multiple articles called "faq",
with expiry dates or supercession as the poster desires. [Hmm, I presume a
cancel would be used to remove a named article once the author feels it is
no longer necessary to have it around ?]

Or you don't have a fixed set of names, and people post "faq-boa",
"faq-smileys", "faq-emily", "faq-active", and so on.

> One answer commonly used today is the web, giving a newsgroup a home page.
> But of course that's non-usenetlike and of no use to offline users.

Agreed.

> If you want more than one you need:
> 	a) A means to define subnames for the variants, so that each
> 	   variant can be independently updated.

A syntax issue. Trivial.

> 	b) Newsreaders then need to be able to get a list of the current
> 	   variants

The fetch command needs to accept some form of wildcards, according to the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane