Re: [stir] Review of: draft-ietf-stir-passport-05

On Sun, Aug 28, 2016 at 8:41 AM, Michael Hammer <
michael.hammer@yaanatech.com> wrote:

> Ummm….
>
>
>
> If any signature can be repudiated by the sender,
>
> then how do you apply any consequences for bad behavior?
>
> Any caller could just say, it wasn’t me and they are off the hook?
>

I don't think I said that. It certainly wasn't what I meant.

>
>
> Isn’t the consequence tree:
>
> -          Not signed:  customer may not answer or caveat emptor
>
> -          Signed, robocall:  crackdown
>
> -          Signed, normal call:  good to go?
>
>
>
> I assume that a signed call that has faulty credentials,
>
> e.g. bad timestamp, unknown signer, could get filtered out.
>
> But, that gets into carrier policy that can’t be standardized.
>

Yes, this is correct.

-Ekr

> *________________________________*
>
> *Michael Hammer*
>
> michael.hammer@yaanatech.com
>
> +1 408 202 9291
>
>
> © 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality
> notice. This message is private and confidential. If you have received this
> message in error, please notify us and remove it from your system.
>
>
>
> *From:* stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Saturday, August 27, 2016 9:54 PM
> *To:* Dave Crocker <dcrocker@bbiw.net>
> *Cc:* Chris Wendt <chris-ietf@chriswendt.net>; stir@ietf.org
> *Subject:* Re: [stir] Review of: draft-ietf-stir-passport-05
>
>
>
>
>
>
>
> On Sat, Aug 27, 2016 at 6:46 PM, Dave Crocker <dhc@dcrocker.net> wrote:
>
> On 8/27/2016 5:19 PM, Eric Rescorla wrote:
>
>     And I believe that was my original guess, although my very limited
>     understanding of non-repudiation includes the significant burden of
>     having the timestamp, itself, be validated by an independent
>     authority. Otherwise, the signer could claim any time they want to...
>
>
> That doesn't seem correct to me, at least if "independent" means someone
> other than the relying party. The signature is itself a proof attaching
> the signer's private key to the passport and to a claim by the signer
> about the passport object's assertions being valid at the time in the
> timestamp. If the relying party checks the timestamp and rejects it if
> it has a bogus timestamp, then any acceptable passport will be
> relatively fresh and thus will be usable as a proof of the signer's
> representation at the relevant time. Overall, this seems less important
> than the freshness property wrt authentication, but it's still a
> technical property.
>
>
>
> This sounds pretty much the same as authentication.
>
> While the verifier might decide that the timestamp is ok, if the
> verification is close enough in time to that claimed occurrence, it does
> nothing for being able to prove the timing to a third-party, /later/.
>
>
>
> Well, what you can prove (at any time in the future) is that the signer
> claimed that a given thing was true at (what it claimed was) a given time.
> You can prove this to a third party.
>
>
>
> This isn't a necessary property of authentication. For instance, the
> relying party could share a key with the passport generator and the
> passport could be secured with a MAC.
>
>
>
>
>
> And that's the environment I'm used to hearing about needing
> 'non-repudiation' for.
>
> In that case, the timestamp needs to have validation that is independent
> of the signer.  What I'm used to hearing, for that, is that an independent
> timestamp service does a kind of notary signature on the original signer's
> stuff, including the timestamp.
>
>
>
> I'm not sure why you think non-repudiation needs a notary signature.
> That's not generally the case, as indicated above, and even if you do have
> a timestamping service, all it can prove is that the signature was
> generated *prior* to a given time, not at a given time.
>
>
>
>
>
> Anyhow, all of seems to go beyond STIR's needs, suggesting that it would
> be best to remove use of the term?
>
>
>
> Yes, I think that would be fine.
>
>
>
>
>
> d/
>
> --
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>