Thursday, November 7, 2013< ^ >
stpeter has set the subject to: KITTEN WG |
Room Configuration
Room Occupants

[23:08:49] Tom Yu joins the room
[23:09:54] <> Looks kind of lonely in here...
[23:10:07] <Tom Yu> it's still the break isn't it?
[23:10:26] <> Yup.
[23:10:37] <> "We can still hear Sam on the stream, though"
[23:11:04] <Tom Yu> Sarcasm as a Service?
[23:11:48] jimsch1 joins the room
[23:13:50] Michael Peck joins the room
[23:15:13] nico joins the room
[23:15:18] <nico> hi
[23:16:00] <> Hi Nico.
[23:16:22] <jimsch1> Is nico audio good?
[23:16:27] <nico> yes
[23:16:32] <nico> say so again
[23:16:34] <> Hi Sean.
[23:16:41] <nico> let's determine latency
[23:16:41] <Tom Yu> audio is much better than in saag
[23:16:46] Rhys joins the room
[23:16:56] <> *Shawn, sorry.
[23:17:09] Scott Cantor joins the room
[23:17:14] m&m joins the room
[23:17:33] <nico> oh, is there webex for this?
[23:17:59] <> I think the room saag was in is known to have very low level on its
[23:18:00] <jimsch1> No
[23:18:19] <nico> ah, ic
[23:18:23] <Tom Yu> i don't see webex information for kitten on the remote participation info page
[23:19:14] <Rhys> i'll be channelling questions to the mic, so if you have anything you want channeled just preface it with mic: and i shall do so
[23:19:46] <> Thanks, Rhys.
[23:20:44] <nico> lol
[23:21:50] <nico> Tom Yu: remind me, did I convince myself that if we specified confounded CTS it would nonethless be possible for a sender to implement explicit IV CTS without the recipient being able to tell the difference?
[23:21:59] MattJ joins the room
[23:22:02] <nico> if so, then we should specify confounded CTS and be done
[23:22:38] <nico> or maybe I'm just dreaming/tired
[23:22:52] <Tom Yu> mic: adoption of the auth-indicator draft?
[23:22:52] <> nico: I think that chaining would break, though it's uncommon.
[23:23:13] <nico> what was the auth-indicator thing?  LoA?
[23:23:22] <nico> I thought there was a separate proposal for LoA
[23:23:23] <> LoA, yes.
[23:23:32] <nico> we do need an LoA indicator
[23:23:54] <> mic: gss-loop draft, too?
[23:23:56] <nico> i think there's a fair bit of lag in the audio, fyi
[23:24:00] <Tom Yu> mic: the author isn't familiar with IETF process and so didn't explicitly ask for WG adoption
[23:24:14] <nico> yes to the gss-loop I-D, it's in charter already
[23:24:36] ghudson joins the room
[23:24:59] <nico> kaduk: right, good point, thanks;
[23:26:29] <> (I think the audio stream is advertised as having up to 10 seconds
[23:26:47] <Scott Cantor> think it's ready for WGLC, but is dependent on an abfab draft
[23:26:53] <nico> what I-D are we on?
[23:27:00] <Scott Cantor> SAML-EC
[23:27:10] <nico> ok, no comments on that yet
[23:27:15] <Scott Cantor> yes
[23:27:19] <Scott Cantor> eap-naming
[23:29:33] <> Coudlnt' hear Jim
[23:29:52] <Rhys> jim said he'd help
[23:30:00] <Rhys> he'd validate what sam did
[23:30:00] <> Yay
[23:31:27] mrex-ietf joins the room
[23:31:44] <> Yes, thanks, Jim.
[23:32:02] <Tom Yu> mic: "other-verifiers" issue is to prevent it from being empty, not to limit its length
[23:33:44] <> mic: or we could not put it in anything at all
[23:34:06] <nico> i don't have it swapped in either
[23:34:07] <Tom Yu> mic: sent a summary to the list earlier today
[23:34:11] <> mic: (which would by the spec mean that implementations that don't
know about it would reject it, but implementations don't)
[23:34:33] <> (belay that last mic; sam covered it)
[23:35:15] <nico> yeah, CAMMAC should be inAD-IF-RELEVANT
[23:35:29] <> nico: you should send mail
[23:35:35] <nico> unless the client or KDC have reason to believe it should not be
[23:35:59] <nico> no, issue a new RFC
[23:36:14] <Rhys> nico: want that mic'd?
[23:36:28] <nico> no, i'm merely not objecting
[23:36:29] <Tom Yu> mic: given apparent resistance to erratum, i support the 6112.bis approach
[23:36:46] <ghudson> nico: Another option is to wrap it in AD-KDC-ISSUED (which is implicitly non-critical) and get rid of the service verifier.
[23:37:03] <nico> ghudson: I don't like that option
[23:37:06] <ghudson> Okay.
[23:37:17] <nico> the reason is that AD-KDC-ISSUED is weak
[23:37:31] <Tom Yu> mic: maybe also ECC support?
[23:37:37] <nico> ECC?
[23:37:47] <mrex-ietf> well, when there _is_ a known problem with an existing RFC, then we **REALLY** should log the problem through the errata process with short delay only
[23:37:51] <nico> wait, what to Standard?
[23:37:54] <ghudson> CAMMAC would be to make up for the weaknesses of AD-KDC-ISSUED.
[23:38:36] <nico> which RFC are we talkig about moving to Standard?
[23:38:47] <> nico: 6112/6112bis
[23:38:55] <mrex-ietf> adding a fix/replacement through errata might be inappropriate if it is a significant change (one that creates interop problems)
[23:39:18] <nico> and yes, for anon PKINIT it'd be nice to have ECC DH, yes
[23:39:18] <Rhys> leif asked if this was an AD question
[23:39:26] <nico> wait, how can 6112bis go to Standard if RFC4120 isn't?
[23:39:34] <> mrex-ietf: I think an errattum has already been submitted for this
[23:39:49] <nico> the erratum should be approved, *and* a new RFC should be issued
[23:40:27] <nico> if the IESG doesn't want to approve the erratum then... what the heck are we doing here?
[23:40:52] <mrex-ietf> there are two "accept" statuses:  verified and "held for document update"
[23:41:07] <Rhys> jim asked "has he said why?"
[23:41:40] <nico> it's a TYPO in a cryptographically-important constant
[23:41:49] <nico> we're wasting precious minutes on something that ought to be trivial
[23:43:03] <> nico: we all love the IETF here, everything is fine and dandy.
[23:43:20] <mrex-ietf> personally, I believe the currently held reservations against fixing problems through errata is _too_ restrictive and doing the community/consumers a disservice (in particular the implementors which are not active in the IETF and do not search WG discussion archives)
[23:43:54] <> mic: I can do some research on some numbers.
[23:44:02] <Tom Yu> mic: sent mail just recently, want some volunteers
[23:44:25] <> mic: (I should also follow up with IANA on the token types, as that
doesn't seem to have moved very much.)
[23:44:57] <nico> kaduk: I know, I'm saying there's no need to agonize over this here; the IESG will approve because they are not perverse
[23:45:08] <nico> if they were we'd not be here
[23:46:21] <mrex-ietf> the ISO process for _accepting_ errata for their specifications looks better suited to the real world, however they seem to be just as bad on making the submited errata accessible
[23:46:31] <nico> mic: I don't see how we can have no mutual auth and -PLUS at the same time
[23:46:49] <nico> mrex-ietf: +1
[23:47:24] <nico> i know, i jumped to the crux of the matter
[23:47:34] <nico> because why volunteer to do something wrong
[23:47:49] sftcd joins the room
[23:49:12] <nico> these are the mechanisms where the mech relies on the app having authenticated the server separately with TLS, right?
[23:49:12] <m&m> nico: do you want that stated at the mic?
[23:49:32] <nico> m&m: no thanks, I'll use the mic: prefix when I do :)
[23:51:06] <nico> mic: I agree with Sam
[23:52:14] <nico> I'd propose -MINUS as a suffix, but that'd be needlessly inflammatory :^)
[23:52:21] <> Haha.
[23:52:37] <> Be sure to cite RFC 6919 as a normative ref.
[23:54:18] <> Now the fun begins!
[23:54:40] <nico> what was that sound
[23:55:53] <> mic: note the mail I sent right before we started, mentioning KDF and
[23:56:17] <nico> mic: I'm happy with confounded and/or explicit IV CTS modes
[23:56:46] <nico> mic: I'd be OK with an explicit IV CBC mode, but I don't think we'll reach consensus for that
[23:56:57] <> I guess we should take it to the list, then.
[23:57:01] <Rhys> i'm in line
[23:57:46] <nico> mic: I'm opposed to using counter modes without updating RFCs 3961 and 4120 to provide for additional key-reuse prevention inputs in the cases of keys other than sub-session keys
[23:57:55] <nico> mic: <done for now>
[23:58:02] <nico> hmm, actually
[23:58:04] <Michael Peck> mic: We posted both CTS and CBC versions of the draft. Happy to go with either. Microsoft is obviously an important implementer.
[23:58:16] <nico> mic: the simplest way forward is to adopt confounded CTS and call it a day
[23:58:20] <mrex-ietf> CBC with either explicit IV or random confounder and pad-mac-encrypt is  GOOD and SAFE
[23:58:20] <> mic: do you have a specific application in mind???
[23:58:21] <Michael Peck> mic: I'm also concerned that counter mode can't be used safely
[23:59:04] <> mic: (a specific application that would have trouble with padding,
that is)
[23:59:33] <mrex-ietf> AES-GCM _might_ be safe within TLS (due to how it derives keys, and aborts on errors) but can be much more dangerous in other environments (including DTLS)
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!