Re: [stir] A few comments on the PASSporT Document

Chris Wendt <chris-ietf@chriswendt.net> Fri, 22 April 2016 00:56 UTC

Return-Path: <chris-ietf@chriswendt.net>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A0712E4C3 for <stir@ietfa.amsl.com>; Thu, 21 Apr 2016 17:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6iqrveZOgqN for <stir@ietfa.amsl.com>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B9512E33F for <stir@ietf.org>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id r184so33106450qkc.1 for <stir@ietf.org>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=kncArM1Y9nqpydtdrpJdB5O2RAxKT4L//Uh7Dp5EtVffdclO0iaOqttCfdCGoyt0WE 70814d2RTklrDIf2KW3mNdJj83yzJ7eyLlIi70V6LTu0uT0WYjdDRPZ2Si4lFuBlVUDN G5n12EUFglJSX/a7JKNtPOzMXcuyf56KGSbFxdusihyB5GH0IUK8mmryOnic+Um7Oi3f KFob5Q48GhLBy0wkV6ZC7bDz7sGigZT94dQgfL/1Ru6493oYyFRVnw3CoUsTXWyxBQ6F aWcZs0wpgdxFD4lN7DI2kiTjQvJdSucoLXpCLlV7/ujGilDY5Axiyht04IVz3LEM/FP1 wJjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=ONPmSo49xGo8WHKGPFqtYZyBBmPTe25EKvEpj8RuzCjF0BrTNPBHLJdF8p3hGPr0TW f52qm7K1NbC5hqK4ZgW1bG1a/sCF0LChipymqv0JdhsMgVXkg056m2XRow1ixU/2AYJR 17vWuaUCkIXfGQlyDs+zWmJlMhouIt4j2hkfQajZY+NBBx9YQWT58qaHZovaF3ECpoat p+uDD7y+3+edGapt5kL11H5/Qn3K55ONygXp/mvBp0Fhz6FYOLePKRxgd+xb4pkdU2cj as3ljVzalnbvzY57cnBTXKO2bUwjyImWsR6sjgu6+y6b597/6+kcvqB/caDlefg4mGgT mrBA==
X-Gm-Message-State: AOPr4FXuHgAxRPKUCyYrwhsJFPwPEEyQQEo1MoAq4cMmLJJYKeE57ywFQPa4xTMSrEXl9A==
X-Received: by 10.55.158.18 with SMTP id h18mr23129090qke.58.1461286611449; Thu, 21 Apr 2016 17:56:51 -0700 (PDT)
Received: from ?IPv6:2601:41:c101:9364:1cce:a470:49b7:fba7? ([2601:41:c101:9364:1cce:a470:49b7:fba7]) by smtp.gmail.com with ESMTPSA id e127sm1414194qkb.34.2016.04.21.17.56.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 17:56:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chris Wendt <chris-ietf@chriswendt.net>
In-Reply-To: <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com>
Date: Thu, 21 Apr 2016 20:56:48 -0400
Message-Id: <6C7F922E-3472-423D-B430-AA87B36C239F@chriswendt.net>
References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> <D33E61AD.187813%jon.peterson@neustar.biz> <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/hFo62Gr7Ub51HEQi-3CWnJ4P3po>
Cc: IETF STIR Mail List <stir@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>
Subject: Re: [stir] A few comments on the PASSporT Document
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2016 00:56:54 -0000

> On Apr 21, 2016, at 4:26 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> Jon:
> 
>> Thanks for these notes Russ.
>> 
>>> I needed to chase a bunch of references to figure out what really goes in
>>> the iat claim.  This leads me to two comments.
>>> 
>>> (1)  Let¹s help the reader and tell them that the iat claim contains a
>>> JSON numeric value representing the number of seconds from 1970-01-01
>>> 00:00:00 UTC.
>> 
>> Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed
>> it would be helpful to informationally reiterate its syntax in the
>> PASSporT spec.
> 
> Thanks.

Agree.

> 
>>> (2) The iat claim carries the time that the token was issued.  Section 7
>>> tells that the token should be handled in a "reasonable for clock drift
>>> and transmission time.²  This makes sense, but neither Section 3.2.1.1
>>> nor Section 7 tells what ought to happen if it is determined to be stale.
>> 
>> This is where the hand-off between RFC4474bis and PASSporT can be murky.
>> The behavior for SIP as a using protocol of PASSporT with regards to the
>> freshness of Date/iat is given in RFC4474bis. Other using protocols might
>> want to use other means to ascertain freshness; SIP behavior really comes
>> down to comparing iat with the Date header, and we don't want that
>> using-protocol-specific language to be in PASSporT.
>> 
>> I can also imagine PASSporT tokens being evaluated historically, rather
>> than in real time, and the determination of "freshness" for those purposes
>> might be different, or even just irrelevant.
>> 
>> What we can say about iat in PASSporT though is that using protocols are
>> required to specify how they determine freshness (like, what they compare
>> it to). Would that make sense as a way to approach this?
> 
> Yes, that makes sense to me.

Agree.

> 
>>> The syntax of the mky claim seems to go against a JOSE design principle.
>>> JOSE used very compact representations for everything.  However, the mky
>>> claim uses a whole lot of colons.  This leads to a third comment.
>>> 
>>> (3) To align with the JOSE principle, should the mky claim syntax use a
>>> hex string or a base64 string to carry the hash values.
>> 
>> Jonathan Lennox provided some compelling reasons for us to move mky to a
>> JSON array format, similar to what WebRTC has done (so it's clear which
>> keys can match to which m= lines in SDP, say). That at least was my
>> take-away from the discussions around this in Buenos Aires. Would that be
>> satisfactory for you?
> 
> I think so.

So, Jon, the idea is to use this format?

{
       "fingerprint": [ {
         "algorithm": "sha-256",
         "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
       }, {
         "algorithm": "sha-1",
         "digest": "74:E9:76:C8:19:...:F4:45:6B"
       } ]
     }

(from 5.6.4) in draft-ietf-rtcweb-security-arch-11

I’m not sure that addresses the size part, do we need the colon’s as Russ suggests?
Maybe use smaller key’s?

{
       "fp": [ {
         "alg": "sha-256",
         "dgst": "4AADB9B13F...E57CAB"
       }, {
         "alg": "sha-1",
         "dgst": "74E976C819...F4456B"
       } ]
     }


Could do even further encoding of fingerprint to reduce size as suggested in https://webrtchacks.com/the-minimum-viable-sdp/ <https://webrtchacks.com/the-minimum-viable-sdp/>

Thoughts?