[stir] stir 95 meeting notes - raw

["A. Jean Mahoney" <[e-mail]>]

Below are my raw notes from the meeting. I marked places where I missed 
stuff with ellipses (...).

Thanks,

Jean


-----------------------------------------------------------------------------------
STIR: IETF 95

Tuesday, Afternoon Session III 1740-1910
Quebracho B

-----------------------------------------------------------------------------------
5m Administrivia

presenter: Robert Sparks
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-0.pdf


Note takers: Brian Rosen and Jean Mahoney
Jabber relay: Sean Turner

Jabber log: http://www.ietf.org/jabber/logs/stir/2016-04-05.html

Note well and agenda were presented. No changes to the agenda.


-----------------------------------------------------------------------------------
10m  Overview of changes across the WG documents

presenter: Sean Turner
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-1.pdf


Brian Rosen asked if it was still true that anyone on path can do the 
verification.
Sean said that it was still true.

No actions.


-----------------------------------------------------------------------------------
30m draft-ietf-stir-rfc4474bis

presenter: Jon Peterson
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-2.pdf


slide 1: Title


slide 2: Divide and Conquer


slide 3: Changes since -06


slide 4: Date Fix

Jonathan Lennox - You need to check for copy-n-paste attacks.

Jon - It's there in the text.

Jon (to the room) - we're cool? The Date fix is the biggest change.

Room had no objections.


slide 5: Extensibility

Chris Wendt - The worst case would be 2 identity headers with two 
tokens. It would nice to combine those.

Jon - Either we build it into ppt or create a MIME type. We can do 
either. There's no good reason to do one or the other. Now we're doing 
nothing. If PASSporT decides to make the MIME type a component of ppt, 
then we don't need to change.

Eric Burger - There might be different network elements that put them 
in. Having multiple headers may be desirable.

Jon - It could. we'll talk about it when we talk about extending with CNAM.

Chris - We want something that can combine them like CNAM.

Jon - It would be nice not to have 15 of these things.


slide 6: Opportunistic STIR

Jon - This is of marginal benefit but still offers some benefit. This is 
not in the main path of deliverables.

Alan Johnston - This is orthogonal to OSRTP. I don't have an opinion on 
this.

Jon - The signature is only as good as the entity that signed over it. 
Can be added without knowledge or consent of the app, but not meddled 
with by a MITM.

Alan - It can't be used in place of OSRTP.

Jon - The draft in dispatch will just point to OSRTP. This doesn't 
replace it. It relies on it. Anyone have a problem with opportunistic STIR?

Room had no objections.


slide 7: Future work

Jon - Please review carefully because of swapping in passport.

Robert Sparks - You need to add a few words about backward compatibility 
into the next draft.

Robert - I see some implementers in room, will you sign up to review?

Martin Dolly, Eric Burger, John Mattsson volunteered

Robert - Is anyone going to SIPit?

Eric Burger - We'll have something.


ACTIONs: Authors to add text on backward compatibility. Martin Dolly, 
Eric Burger, John Mattsson to review draft-ietf-stir-rfc4474bis.


-----------------------------------------------------------------------------------
30m draft-ietf-stir-passport

presenter: Chris Wendt
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-3.pdf


slide 1: Title


slide 2: Overview


slide 3: PASSporT Header

Sean - Have you already registered the MIME Type? It's really easy. Just 
send me email and I can help with that.


slide 4: PASSporT Payload


slide 5: PASSporT Payload


slide 6: PASSporT Payload - Identity Types

Jon - What about Dr. Hardie's comment that they need to be strictly 
typed and extensible? We're not excluding WEBRTC.

Richard Barnes - What about Tel URIs?

Jon - We using otn and dtn. We won't do tel URIs because we want it to 
be canonicalized.

Chris - Should we forbid tel URIs? A passport can have tel URIs, but it 
wouldn't be for 4474bis.

Brian Rosen - a ... is a pretty straight forward thing to canonicalize.

Jon - I'd rather see a phone number in otn and dtn and explain what we 
mean. I would prefer not to see a tel URI.

Chris - You don't have an option for telephone numbers. Must use otn and 
dtn.

Jon - Let me look at it.


slide 7: PASSporT Payload - Media Key

Jon - If it's a telephone number, then use otn and dtn. 4474bis allows 
ouri and dturi.

Christer Holmberg - There are multiple fingerprints.

Chris - It's covered in the text.

Jon - They're alphabetized and concatenated. This is a misalignment 
between passport and 4474bis now. When we'll get to serializing, I'll 
get to it.


slide 8: Multi-Party Communications

Richard - When doing .... you may be tempted to do a string and then 
array, don't.

Chris - There's nothing to prevent it. That can happen in passport and 
4474bis.


slide 9: Extension to PASSporT base claims


slide 10: Extending base claims


slide 11: Extending base claims


slide 12: Defining new set of claims


slide 13: Registering PASSporT extensions

Chris - Any opinions on registering extensions?

Jon - We want to make sure we understand what we're asking people to do. 
People need sufficient guidance when extending passport. What are 
pitfalls? We need to get that language correct.


slide 14: Deterministic JSON serialization

Jon - We can replace the whitespace with a dot or something.

Chris - Or we can just remove it.

Jon - With non-SIP protocols this may be the only place the info is. If 
we want people to be able to look at it. It's not terribly confusing. If 
there was a new session negotiation protocol, and it chose to use 
passport, what would be the form to use? Our responsibility is to be 
more semantically clear. One part gives the algo for the keying. 
Multiple algos listed. The other part, separate.

Chris - a JSON array.

Jon - If it's a one-way hash, it can be crunched together.

Robert - For debugging, I can't think of many cases of visual ambiguity, 
but SHA25 and the first characters are 25 is one.

Chris - ...

Jon - If we're passing the entire object outside of SIP, then base 64 
could be appropriate. In SIP, it should be as human readable as 
possible. Not base 64. I think this is an open issue. We can take a 
couple of cracks at it. We can explore alternate key mechanisms. New 
keys for JWS. It may be sufficient for STIR. We need to get this done. 
We may revise this with an array going forward.

Chris - We should have guidelines for future claims. But we don't have 
text yet. Other than "no whitespace".

Jon - JWS gives guidance. Need to think of semantics. I would prefer to 
see separable characters. Keep the semicolon. Good enough. Anyone here 
upset?

Richard - Don't worry about whitespace in the the JSON string, you'll 
have other problems.

Eric - We can deal with the space.

Chris - I'm ok with the period.

Jon - Have a separator.

Richard - I see no reason why a decoder would want to enforce that.

Russ - It's so that it can hash the same string. Go away.

Chris - Space or period?

Eric - period or vertical bar?

Brian - vertical bar looks too much like an I.

Richard - Use template filling. Write the template in the draft. ...

Jon sends Richard to the corner.

Chris - We'll use a period.

Jon - We need to provide an example. Last meeting, someone was on the 
hook on this. We need to show whole shebang.

Robert - I was supposed to find someone to do the example. Cullen was to 
help me. I would like to borrow from the passport document. Show 
multiple fingerprints in an example.

Chris - I have a tn and uri in that example.

Sean - I want to see an elliptic curve example.


slide 15: Examples


slide 16: passport-02

Jon - I'd like to talk about ECC. There is an email saying we should 
move away from RS256. JWT uses this, which is why we are using it.

John Mattsson - ... both are required.

Jon - This is a certs issue as much as a passport issue. Can I get this 
from web CAs today? No. We can be forward-looking in our implementation. 
Will use existing web PKI from web CAs. There are people who want to use 
commercial web CAs. If we assume that we will build all new CAs for 
this, I've been told that will take too long. Telling regulators that 
we'll wait for implementers is unacceptable. If we can turn on this year.

Chris - EC256 has CPU benefits.

Richard - ECC is technically better.

Chris - can we say both with a preference?

Richard - ECC are generally available in the modern CA market. If you 
use Web PKI, you have to commit to move as fast they move. Getting 
behind means that the devices cannot work. It's worth having a system 
that has its own CAs.

Chris - For future proofing, should we recommend higher keys as well? 
384, 512?

Richard - I don't think I understand. You don't want to specify a single 
elliptic curve. You can say 256 is mandatory to implement and 384 is 
optional. Ensuring that your software is upgradable is an implementation 
issue.

John Mattsson - DHA (? ECDSA?) should be required and RSA is optional.

Chris - CPU

Sean - We need to get this out in 9 months. Would have to stick with 
RSA. You can get elliptic curves. Verify both - be liberal in what you 
receive.

Chris - I like that conclusion.

Jon - Small keys are great. I listen to Russ, Sean, and ekr. I don't 
know about when it's ready for runtime. Russ, please chime in. I don't 
have an opinion.

Russ - Do you need one mandatory to implement. Or can you verify both?

Jon - I'm cool with verifying both.

Richard - Let's Encrypt will have free ECC certs available in the time 
frame.

Eric - One and only one is the way to go. ECC certs will be available. 
Why should we make ourselves do more work?

Russ - Very few EC certs are available today.

Eric - Only one country will be doing this anytime soon, and in that 
market, it doesn't matter that it's a small handful.

Jon - It will matter when you are dragged in front of the FCC. Saying 
that we can't do this today makes me nervous. People want it done today.

Chris - Have it there and then move to ECC.

Jon - This sounds like a road block.

Robert, as chair - I'm not seeing pushback on verifiers having to 
implement more that one algo.

Eric - It's only money.

Robert - If you don't have a cert that uses the ECC, you won't exercise 
that code.

Russ - My sense of the room is that we have verification of both RSA and 
ECC signatures so that we can have a smooth transition to ECC.

Sean - .... why you didn't use the phone number. Add explicit text.

Jon - JWS registration for claims doesn't require a lot of text, but we 
can provide text.
Non-normative text about why we're aren't using the current JWT claim 
for telephone.

Jon - Need to align on MIME type versus ppt.

Chris - we can chat about it. A plus in between - can we settle on that?

Jon - let's just do that. Get this done.

Robert, as chair - There are just a few minutes left in the meeting. 
Should we break and pick it up next session?

Martin Dolly - You need to make extensibility very clear in the 
examples. For instance, I'll be writing up extending passport for the 
Resource-Priority header. I'd like to write that doc in ADIS and do the 
registration in the IETF.

Russ - We had planned to discuss this today, or we can discuss in the 
next session.

Jon - We can do it now.


ACTIONs: Authors to register the MIME type (Done). Have verification of 
both RSA and ECC signatures.


-----------------------------------------------------------------------------------
15m Passport extensibility

presenter: Jon Peterson
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-4.pdf


slide 1: Title


slide 2: Twofold STIR extensibility model


slide 3: Testing extensibility


slide 4: The "cna" extension


slide 5: Elaborating on "cna"

Brian Rosen - in your example, you didn't sign the display name in the 
SIP headers, you created a new CNAM thing.

Jon - the draft does, the slides don't.

Brian - all I care about is taking a base type and adding a subtype to it.

Jon - I think it does. If the new claim is not in the SIP message, you 
MUST include canon. Resource-Priority will not require canon.


slide 6: Should we test MIME as well?


slide 7: Sanity checking


ACTIONs: None


Russ - have a good evening.

EOM