On Thu, 04 Jan 2007 19:38:12 -, Scott Kitterman
[EMAIL PROTECTED] wrote:
From my perspective having a message have a valid signature with one
implementation and having a broken signature with another is an
incompatibility. I don't think that's speculation. I think it's the
clear
and
On Thu, 04 Jan 2007 05:31:25 -, Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
I think we have to weaken it since it is not an interoperability issue.
If I choose to give you information I cannot regulate the use you make
of it (absent DRM).
A MUST NOT has a particular meaning for
Hi Hector,
Hector Santos wrote:
If anything, change this text:
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
to:
Verifiers MAY use the header field names or
On Wed, 03 Jan 2007 21:38:41 -, william(at)elan.net [EMAIL PROTECTED]
wrote:
On Tue, 2 Jan 2007, John Levine wrote:
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be
Stephen Farrell wrote:
If anything, change this text:
...
I think we need some text containing no MUST/SHOULD/MAY at all,
The current text was the result of significant discussion and a rather careful
effort to focus on the primary concern.
Take out the normative quality to the text
Dave Crocker wrote:
Stephen Farrell wrote:
If anything, change this text:
...
I think we need some text containing no MUST/SHOULD/MAY at all,
The current text was the result of significant discussion and a rather
careful effort to focus on the primary concern.
Sorry, I should have
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker
Stephen Farrell wrote:
If anything, change this text:
...
I think we need some text containing no MUST/SHOULD/MAY at all,
The current text was the result of significant discussion and
a rather careful effort to focus on the
[mailto:[EMAIL PROTECTED] On Behalf Of Charles Lindsey
I just want to point out that similar arguments also apply to
the MUST sign the From header case.
I disagree, I can easily write a test vector for that MUST so it is emprically
verifiable. Hence it can be made a MUST.
In general we
Doug,
You are repeating yourself, yet again. As far as I can see
all this was raised by you before and none of it achieved
WG consensus.
Feel free to try convince Barry and I otherwise, *off-list*,
but please do not continue to try to reopen closed issues
on the list.
I see all this as being
As a result of this thread, the WG consensus on the MUST NOT for
z= might have changed. In order to see if that's the case, we need
someone to suggest alternate text.
IMO, we need some text that (a) makes it clear that a signature
verification which conforms to this standard must not be
On Jan 4, 2007, at 7:34 AM, Stephen Farrell wrote:
Doug,
You are repeating yourself, yet again. As far as I can see all this
was raised by you before and none of it achieved WG consensus.
Feel free to try convince Barry and I otherwise, *off-list*, but
please do not continue to try to
Can you describe the algorithm to distinguish the cases where the original
value is fine from the cases where it's not?
You took one line without additional context where I gave an example of users
who have processing script to find mail lists based on subject tags.
We all have scripts like
[mailto:[EMAIL PROTECTED] On Behalf Of Arvel Hathcock
I believe the current text is meant to do (a) but the
checking the signatures in any way language implies (b).
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied
John L wrote:
I think that we all agree that if the intermediate system re-signed
the message and we trust that signature, the message is OK. But the
discussion in progress is, as far as I can tell, about messages where
an intermediate system modified but did not re-sign.
I don't think it's
On Thursday 04 January 2007 12:24, John L wrote:
Actually, that's not at all what I was talking about. I was asking how a
recipient system can algorithmically distinguish an upstream modification
that broke the signature but was ok from one that wasn't.
This is, I think, the key point. All
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
1) This condition is ACTUALLY REQUIRED for interoperation?
Well, yeah. If the verifier is a separate module from the one
From: John Levine [mailto:[EMAIL PROTECTED]
Subject: Re: [ietf-dkim] Base issue: multiple linked signatures
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
1
On Thu, 4 Jan 2007, John L wrote:
Can you describe the algorithm to distinguish the cases where the original
value is fine from the cases where it's not?
You took one line without additional context where I gave an example of
users who have processing script to find mail lists based on
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman
While there is certainly nothing an RFC can do to prevent
receivers from attempting to do the kind of message reverse
engineering being discussed, the current MUST NOT wording
makes it clear that the results of that processing are
On Thursday 04 January 2007 14:18, Hallam-Baker, Phillip wrote:
The rules are very clear, MUST can only be used in cases when breaking the
rule will inevitably produce incompatibility.
Speculation that breaking the rule might produce incompatibility is not
enough. RFC 2119 is very clear.
On Thu, 04 Jan 2007 12:23:54 -, Stephen Farrell
[EMAIL PROTECTED] wrote:
When we've a reasonable looking alternative, then we can ask the
change/no-change question.
If you simply s/MUST NOT/SHOULD NOT/, then you are saying, in effect:
When used for the purposes and in the manner
On Thu, 04 Jan 2007 14:23:06 -, Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Charles Lindsey
I just want to point out that similar arguments also apply to
the MUST sign the From header case.
I disagree, I can easily write a test vector for
On Tue, 02 Jan 2007 16:48:59 -, John Levine [EMAIL PROTECTED] wrote:
I would support some gentler language that permits use of z= in
verification, with particular attention paid to ensuring that a new
security vulnerability is not introduced.
So I still think our decision to stay away
Well, happy new year all.
Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the MUST NOT
on the z=. Correct me if I'm wrong there.
Was there a suggestion for new text for the z= that we can
consider? (Sorry if I missed it.)
Thanks,
Stephen.
Charles Lindsey wrote:
On Tue, 02 Jan 2007 18:11:06 -, Douglas Otis [EMAIL PROTECTED]
wrote:
I agree. An unsigned From is a cause for suspicion, but there may
sometimes be valid resons, which the verifier should be allowed to
consider. For example, in EAI the From may get downgraded
On Wed, 03 Jan 2007 10:58:20 -, Stephen Farrell
[EMAIL PROTECTED] wrote:
Well, happy new year all.
Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the MUST NOT
on the z=. Correct me if I'm wrong there.
No, weakening it is all I am
On Tue, 2 Jan 2007, John Levine wrote:
I would support some gentler language that permits use of z= in
verification, with particular attention paid to ensuring that a new
security vulnerability is not introduced.
My recollection is that we had no idea what the security
vulnerabilities would
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the modification was as an option.
That's one
On Wed, 3 Jan 2007, John R Levine wrote:
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the
-dkim] Base issue: multiple linked signatures
Well, happy new year all.
Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the MUST NOT
on the z=. Correct me if I'm wrong there.
Was there a suggestion for new text for the z= that we can
Stephen Farrell wrote:
Well, happy new year all.
Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the MUST NOT
on the z=. Correct me if I'm wrong there.
Was there a suggestion for new text for the z= that we can
consider? (Sorry if I missed
I would support some gentler language that permits use of z= in
verification, with particular attention paid to ensuring that a new
security vulnerability is not introduced.
My recollection is that we had no idea what the security
vulnerabilities would be, nor did we have any proposals for a
On Jan 1, 2007, at 10:19 PM, Jim Fenton wrote:
1. There is nothing in the base spec that precludes multiple
signatures from being used in this way, except for the requirement
in Section 5.4 that the From header field MUST be signed. So it
wouldn't be possible to detect a modification to
DKIM Chair wrote:
In discussions with the IESG to sort through their discuss comments,
I had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple signatures, multiple *linked* signatures,
On Tue, 26 Dec 2006 16:36:39 -, Michael Thomas [EMAIL PROTECTED] wrote:
DKIM Chair wrote:
One way this might be used is to have one signature that covers the
subject header and one that doesn't, to allow the verifier to detect a
subject change and decide whether it's OK. As the spec
EKR wrote:
Paul Hoffman [EMAIL PROTECTED] writes:
At 3:43 PM -0800 12/26/06, EKR wrote:
I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for
On Dec 28, 2006, at 6:19 AM, Michael Thomas wrote:
There's two ways to read this restriction: one is that you should
never do this under any conditions which ventures into silly
net.cop delusions of what the protocol document can mandate, and a
more innocent caution that the actual
On Dec 28, 2006, at 4:06 PM, Scott Kitterman wrote:
This seems quite simple to me. If the domain owner doesn't care
about protecting headers, they should not sign them. If they care
about protecting headers from being modified, they should sign them.
The presence of a failed signature
On Dec 26, 2006, at 5:24 PM, Hallam-Baker, Phillip wrote:
I don't quite see what the objective is here.
There is a lot of information that a sufficiently dedicated client
might infer from multiple signatures made by the same signer but I
am not sure that there is much value to be gained
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Levine
Sent: Tuesday, December 26, 2006 8:24 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Base issue: multiple linked signatures
Verifiers MUST NOT use the header field names or copied values
for checking the signature
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
Did we really put this in base? Yes we did.
Its not enforceable as it is at the option of the receiver and so cannot
On Dec 26, 2006, at 10:22 AM, John Levine wrote:
I don't understand what the security model of linked signatures
would be, and I doubt anyone else does, either. Since DKIM allows
multiple signatures now, and allows you to put private fields in
the signature header, there's plenty of
From: John L [mailto:[EMAIL PROTECTED]
Its not enforceable as it is at the option of the receiver and so
cannot be a MUST NOT, it could be a SHOULD NOT.
Seems to me this is a semantic niggle. People can implement
whatever variant form of whatever spec they want to, but if
they
In discussions with the IESG to sort through their discuss comments,
I had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple signatures, multiple *linked* signatures, which
could work
DKIM Chair wrote:
In discussions with the IESG to sort through their discuss comments,
I had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple signatures, multiple *linked* signatures,
Barry,
DKIM Chair wrote:
In discussions with the IESG to sort through their discuss comments, I
had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple signatures, multiple *linked*
discussions of multiple signatures, multiple *linked* signatures,
which could work TOGETHER to convey information, and the protocol
doesn't allow that sort of thing.
We have certainly beaten to death the issue of whether signatures can
or should survive mailing lists, an aspect of the
On Tue, 2006-12-26 at 11:21 -0500, DKIM Chair wrote:
In discussions with the IESG to sort through their discuss comments,
I had a talk with Lisa Dusseault, and she had one point that I want to
bring back to the mailing list: I don't think we considered, in our
discussions of multiple
At 11:21 AM -0500 12/26/06, DKIM Chair wrote:
In discussions with the IESG to sort through their discuss
comments, I had a talk with Lisa Dusseault, and she had one point
that I want to bring back to the mailing list: I don't think we
considered, in our discussions of multiple signatures,
discussions of multiple signatures, multiple *linked* signatures,
which could work TOGETHER to convey information, and the protocol
doesn't allow that sort of thing.
We have certainly beaten to death the issue of whether signatures can
or should survive mailing lists, an aspect of the
I agree with the below. There is already a means to determine what
header change broke the signature (assuming a signer is interested in
providing the necessary data) and assuming a verifier even cares.
--
Arvel
Paul Hoffman wrote:
What is being proposed above is that an additional signature
I emphatically agree. I will also note that a comparable set of tools are
provided by multipart/signed to MOSS (not that anyone cares about MOSS any
more), PGP, and S/MIME, and pretty much nothing has come of it. Maybe DKIM will
be different, but while I'm optimistic that DKIM will see better
Paul Hoffman [EMAIL PROTECTED] writes:
At 11:21 AM -0500 12/26/06, DKIM Chair wrote:
In discussions with the IESG to sort through their discuss
comments, I had a talk with Lisa Dusseault, and she had one point
that I want to bring back to the mailing list: I don't think we
considered, in
At 3:43 PM -0800 12/26/06, EKR wrote:
I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for each
one. Rather, you could simply include digests for the
Paul Hoffman [EMAIL PROTECTED] writes:
At 3:43 PM -0800 12/26/06, EKR wrote:
I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for each
one. Rather, you
I don't know what's being proposed here, but as a technical matter
I believe Lisa has said she will post more specific details under her discuss,
so that we can be more clear about what she is seeking from the working group.
And she had indicated that some of her views and concerns have
On Tue, 2006-12-26 at 15:43 -0800, EKR wrote:
I also discussed this with Lisa, and came to a very different conclusion.
What is being proposed above is that an additional signature be
generated and validated for every important header. That is a huge
waste of energy, and it will cause
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
But of course that restriction could be relaxed.
My recollection is the point of that restriction is that a verifier
something that
is beyond base.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of EKR
Sent: Tuesday, December 26, 2006 7:08 PM
To: Paul Hoffman
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Base issue: multiple linked signatures
Paul Hoffman
59 matches
Mail list logo
