Subject: Re: Last Call: draft-duerst-archived-at (The Archived-At Message Header Field) to Proposed Standard

From: Martin Duerst <[email-masked]>
Date: Mon, 20 Aug 2007 13:35:22 +0900

Hello Stephane,

At 09:32 07/07/22, Stephane Bortzmeyer wrote:
>On Thu, Jul 12, 2007 at 10:03:00AM -0400,
> The IESG <[email-masked]> wrote 
> a message of 24 lines which said:
>
>> - 'The Archived-At Message Header Field '
>>    <draft-duerst-archived-at-07.txt> as a Proposed Standard
>
>I've reviewed the document and I find it OK. I also regard the use
>cases presented in section 3.3 as realistic and important so I support
>the idea of such a standard.

Thanks!

>Two remarks, only details:
>
>1) Section 3.2 suggests, to avoid a DoS if the Message-ID is used to
>construct the link, to "offer multiple choices in the response". This
>does not really mitigate the DoS. An attacker could send 1000 messages
>and the only legitimate one would be quite lost among the 1001
>responses.

Good point. At least, to most users that would show that something
is amiss, which could then lead to a fix.

>It seems a general case of "you should not let the client
>control the URI space if this client is unauthenticated".

I added "by using some authentication mechanism on incomming messages"
as a way to address this issue.

I have also figured out that instead of just checking the message-id,
the whole content of a message can be checked. If it's significantly
different from an earlier message with the same message-id, it can
be discarded. As a consequence, the whole section now reads as follows:

Implementations such as that described above can introduce a security
issue. Somebody might deliberately reuse a message id to break the link
to a message. This can be addressed by checking incoming message ids
against those of the messages already in the archive and discarding
incoming duplicates, by checking the content of incomming duplicates
and discarding them if they are significantly different from the first
message, by offering multiple choices in the response to the URI, or
by using some authentication mechanism on incomming messages.

>2) Section 5.2 suggests to register the old experimental header
>X-Archived-At. I am not sure it is compliant with RFC 3864 to register
>private-use headers. I notice there is currently not one "X-something"
>header in the IANA registry. Is this section really necessary?

I think the general idea of the registry was: document what's
(or what has been) used. An additional advantage of putting this
into the registry is that people who have been using this get
a pointer to the newer header. I have copied Graham Klyne, the Expert
Reviewer for that registry, on this email. I'm not totally sure,
but it might actually have been his idea at one point to put
the X-Archived-At header in the registry.

I have added your name to the Acknowledgments section.
Please tell me if you'd prefer not to be listed there.

Thanks again and kind regards,     Martin.

>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>
>iD8DBQFGoqWpQTZHl5fW0kYRAmRzAJ9+ecSEEoDYBkQ0peTDKtEduBDd6ACePeGx
>QFlMmkbaJrqGhgeutsjmkzo=
>=LFt5
>-----END PGP SIGNATURE-----

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf