On 6/20/2014 11:43 AM, John Levine wrote:
>> Question to the group: Does silent discard help? Or rather, do we have
>> any indication that noisy "p=reject" does or can hurt?
>
> ADSP had silent discard.
Sorry, I meant to indicate an interest in usage that was, well, you
know, actually used...
> DMARC has p=quarantine. In discussions with people running large mail
> systems, they said they thought about it and decided it would not be
> an improvement.
That could be worth getting some consensus documentation on.
>> The DKIM specification leaves it to the receive-side evaluator to decide
>> whether "enough" of a message was covered and whether the signature was
>> "sufficiently" strong. If engines are currently ignoring this issue, we
>> have a deeper problem, IMO, and should focus on fixing that, rather than
>> treating it as an acceptable given. ...
>
> I don't know anyone who's checked whether DKIM validators verify the
> version number, but if it's an issue, there aren't that many widely
> used DKIM engines so it wouldn't be hard to check. It seems to me
> it's a lot easier to verify a specific check for a version number than
> an ill defined acceptance of "too weak" signatures.
Once you've classed the task as touching existing engines, then we
should touch them strategically and not merely with a tactical hack.
> It's also not clear to me that there is any reason for a verifier to
> care about the strength of a signature. If a signer wants to put weak
> signatures on mail and take the risk that his reputation will be
> sullied by heavily mutated messages, that's not the verifier's
> problem.
Actually, it is, since it is the verifier's system that will let the
mail get delivered, or not, to an associated mailbox. It is /their/
users who will be most directly affected.
Or, at least, I have assumed that is why folks are so concerned about
the increased ability to do a replay attack if the signature is 'weak'
(mostly meaning, doesn't cover the body.)
> (Note that this is not the same as what I'm proposing, a
> weak signature that is valid only if there is an additional signature
> from a second signer that I trust to put on a reasonable signature.)
Right. Adding a Policy layer.
>> Adding a requirement that one validation needs to be accompanied by a
>> particular other valid signature is just such an additional factor.
>
> I don't see it that way.
Try harder.
>> In my version, at least, the second
> signature is part of what makes the signature valid, just like a body
> hash that matches the body or an expiration date that hasn't passed.
One can always define things in a way that conflates issues that should
be layered. That doesn't make it the right architectural choice. TCP
and IP used to be a single entity.
Adding architectural structure and modularity is a discipline.
Subroutines aren't "required" but they certainly make code a lot
cleaner. The same holds for protocol specification.
So on the question of conflating usage of a validated signature with the
validation process, I'll offer my usual quote from my favorite engineer:
"We can do that, but it would be wrong."[1]
> It's not a matter of opinion, it's either there or not.
How did you come up with 'opinion' as relevant to the discussion here?
>>> With respect to Stephen's concern about libraries knowing when to
>>> construct v1 or v2 signatures, really, that's no big deal. We've been
>>> doing that sort of stuff for version bumps since approximately
>>> forever, and it's a nit compared to the other stuff it'll have to do
>>> to interpret the conditional signatures.
>>
>> Please point to details on the long history of successfully doing
>> version bumps in Internet protocols. I'm not aware of it.
>
> ssh seems to work OK with versions 1 and 2 both in use
There is some irony in citing ssh, given things like:
Prevent SSH from advertising its version number
http://serverfault.com/questions/216801/prevent-ssh-from-advertising-its-version-number
But yeah, this sounds like version numbers work /really/ well:
RFC 4253:
"5.2. New Client, Old Server
Since the new client MAY immediately send additional data after its
identification string (before receiving the server's identification
string), the old protocol may already be corrupt when the client
learns that the server is old. When this happens, the client SHOULD
close the connection to the server, and reconnect using the old
protocol."
> NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661)
Except that the usage model is more like SMTP options, or completely
independent dual stack:
RFC 5661
"NFS version 4 minor version 1
has no dependencies on NFS version 4 minor version 0, and it is
considered a separate protocol. Thus, this document neither updates
nor obsoletes RFC 3530."
Wow...
>>> It also occurs to me that there are all sorts of ways that a
>>> conditionally valid signature would be useful. For example:
>>
>> The signature is not "conditionally valid". The signature validates or
>> it doesn't. Binary choice. That a signature is what we are calling
>> weak does not make it more or less valid.
>
> By "conditionally valid" I mean more conditions the verifier uses to
> make the binary choice. Better wording always welcome.
Having an added layer of policy-related /usage/ of a validated signature
is quite different from the question of whether the signature validates.
d/
[1] Nixon, R. Watergate tapes. March 21, 1973.
http://www.huffingtonpost.com/mitch-rofsky/history-reexamined-waterg_b_838716.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
