Re: [sidr] Audio timestamps from IETF74 San Francisco

[Samuel Weiler <[e-mail]>]

The recent discussion of IETF 75 minutes reminded me that I never 
followed through with posting my notes from IETF 74 in San Francisco.

A few months ago, I went back and listened to the audio archive of the 
San Francisco meeting.  Here are my notes from listening again.  In 
some places it's word for word; in some places paraphrased.  I believe 
the substance was accuately captured, though I'm sure the detail was 
not.

Perhaps these will be helpful to someone, particularly given the 
sparse minutes from that meeting.

Numbers in brackets are timestamps from the MP3, noting that the
meeting starts about 11 minutes into that MP3.

--

No amendments to the agenda; George as jabber scribe, Geoff as minute
taker.

Greg Lebovitz promoting the kmart work, for authenticating peering.
Intent is to add key management, in part to keep operators from
knowing keys.

[17:50] Matt Lepinski re: architecture draft.  Removed text re: trust
anchors and defualt trust anchor text.  Now points to separate
draft.  Also removed text on ROA usage; that should be in the
validation draft.  thanked Danny McPherson for his review.  Another
change suggested by George and Geoff re: subject names in
certificates.  Background: although RIRs may have meaningful subject
names, other certs should (must?) not.  To make barrier to entry as
low as possible, not asking CAs to do identity verification.  One
property vital for certificate paths, but name should be unique among
certs from one CA.  Previously: recommendation had been: DN should
only have a CN attribute w/ meaningless string.  Recommendation is now
to use two attributes: a CN and a serial number.  APNIC wants a string
that persists across reissues.  Serial can be chosen in any way.

Randy: why are RIR/NIR names meaningful, but not IANA/other LIR?
Matt: no good answer.  Randy: then maybe you shouldn't do it.  Steve
Kent: IANA is suppeded to be included along w/ RIRs.  Answer for LIRs:
don't want impose a requirement to verify right to use naame.  It's
believed that the small set of IANA/RIR does not pose a problem.

Randy (off-mike).  [23:06] You're certifying those names, therefore?
Who'se certifying RIPE's name?

Kent: RIPE is.

Randy: So I, as an ISP, could certify my name?

Kent: If you want to be an island and not be certified by anybody else
of course one could do that...

Randy: Ah, so you're saying because the RIRs are self-certifying their
names, but LIRs can't?  I'm confused.

Kent: Well, I do have the name of a doctor.

<laughter>

Randy: Unfortunately, my insurance is only good in Japan.  Although,
they gave me travel insurance, but I can't read it -- it's in
Japanese.

Kent: it's probably only good for getting you back to some other place

[further discussion of insurance]

Kent: the names for those entities are presumed not to be contentious.  And...

Randy: If the name for verizon contentious, Jason?

Kent: since I worked for them, yes.

Randy: but you know what I'm getting at...

Kent: ...

[24:33; more redacted]

Randy: either people are first class citizens or they're not; ...

Kent: the rationale was.....

...

[25:30]

Sandy: What advantage is there for having the RIR's name certified?

Kent: I'd say the only advantage is it makes it easier for someone
encountering one of those certificates to tell which of the small
number ... it's associated with.  We could do away with that, also;
it's a human factors issue...

Sandy: Are other CAs forbidden from using the name that's in the RIR cert?

...

Sandy: They're choosing an abitrary string...

Kent: no, in most PKI's, a subject proposes the name they want a CA to
sign/attest to.  This one does not have that property.  In this one,
the name is assigned by the issuer... to make it easy to match up with
their internal databases and in order to avoid liability associated
with having to verify someone's assertion about their right to use
those names.  Avoid turning them into DNS registrars....

Sandy: I understand.  So having the RIR named in its cert
would.... are other CAs... forbidden to choose one of those set-aside
names?

Kent: among the ones to get to do that...

Randy: I beleive she's asking: am I, as a member of JPNIC, can I ask
that my subject name be IIJ?  Is that correct?

[27:50]

Sandy: No, I was asking: I'm IIJ, and I'm issuing certs; am I
forbidden to put JPNIC or RIPE or APNIC or whatever in the name field?

kent: this allows a CN.  If you chose to do that, you'd be, from my
perspective, needlessly incurring liablity, but from a mechanical
standpoint, the system would still work.

...

Sandy: your stated advantage to having APNIC, RIPE, JPNIC in the cert
is that people could look at it and say "ah! this is an APNIC cert."
If other people might have the ability and right to put those names in
the certs that they produce, you can't be certain, looking at the
name...

Kent: the policy says NOT to do this.  I was answering the mechanical
question of "could you stuff it in here".  the answer is: within those
syntactic constraitns, one could, but it would not be consistent with
the policy, I believe.w

Randy: I'm trying to understand the word "meaningful" up there, in
this context.

Roque: Steve, is this distinction.. can be moved to the CPS, so each
CA can do different things?  In our case, if we have to put meaningful
inofrmation in the CN, it's difficult to know what's meanginful in the
DB....

Kent: was the question "Could you just move this to a CPS?"

Roque: yes

[30:19]

Kent: if we are establishing syntactic constraints overall, then no,
that wouldbe bad.  This is a slippery slope.  ...  I'm reluctant to go
down that path.

Randy: the best way to keep off slippery slopes is don't start on them.

[31:00]

Rob A: I have a slightly different minor issue, leaving the polictcs
out: the current text appears to be recommending that I have stable
common name, as opposed to giving me the OPTION ... what if I don't
want to have a stable common name? ...  I'm not the architecture
should be saying that I should have a stable name; that seems a little
strong.

Matt: sure.

Geoff: i should explain the origin of the request from APNIC to the
document author.  The previous version of the draft precluded any
other form of name expression other than this varying CN, and the
implementation being done by APNIC wanted a structured namespace where
one part was indeed persistent and identifed a database key and the
other part varied with rekeying.  wehen we put the request in, it
became a signle model that said it must go the other way.  we didn't
ask for that.  We just asked for the restriction to be lifted.
... [more freedom] is cool by us; we're not trying to constraint what
others may do ...

Rob: I'm fine with what I think I just heard Geoff ask for.

Matt: the next version of the architecture draft will clarify that
text. ...  I apologize.  The open Q which needs to go to the list are
whether RIR/IANA/etc. names should be prescibed as meaningful or
whether we should make the blanket statement that names are intended
to convey identity.  Hopefully we'll get that clarified.

Matt: another issue: the current text has an example of how one RIR
would delegate resources to another RIR.  For ERX or future xfer...
this demomstrates how the RIR root certificates; how their trust
anchor material need not be reissued to accomodate such a transfer.
first Q: is this example helpful? ...  #2: whether arch doc or some
other doc should clarify the make-before-break principle -- there is
some propagation time inherent in issuing new certs, publishing ROAs,
relying parties fetching, so it is important that you authorize the
new routing before revoking old routing.  This came up in discussion
of this example.  Perhaps the architecture draft or another doc should
clarify that this is an important principle here.

Terry M: ERX example should be removed in light of the TA draft; I
don't see that it has any validity anymore.

Matt: Good.  One slide on ROAS format draft; it has not been revised,
but I'd like to revise it after the meeting.  there was a minor issue
at last meeting re: overlapping prefixes in a ROA [37:08].  For
example, a single ROA could include authorization for 10.0.0.0/8 w/
maxlen 10, ... and 10.1/16, and these would be overlapping.  and this
is a meanginful authorization.

Rob A: if the intent is to allow this, please make it explicit.

Matt: currently there is nothing that explicitly permits or denies, so
I'm going to ... explicitly permit this type of behavior.

Randy: from user point of view, I can obtain the same semantics by
issuing two ROAs.

Matt: yes.

Randy: I would check with implementers whether getting away from
canonic 3779 is annoying to you.  .....

Rob A: that occuured to me.  It is a bit of a pain.  The code I wrote
years ago tha's in openssl doesn't like this overlap.  the reason I
didn't make an issue of it is that Robert Kistileki argued me into the
groud on this at a previous SIDR meeting and I conceded the point that
we needed this because he thought he had a use case.  I don't
remember....

Matt: my recollection is that you and Randy both expressed concern.
Robert, Ruediger, and Mu Huston had all thought that it was a
reasonable thing for us to do.

Ruediger Volk: from POV of plain users, having such an irregularity
that you have to split off ROAs in some cases and not others is pretty
unwelcome and come as a bad surprise at some time.  In the end,
envisioning nice programming systems that procide nice user
interfaces, it also could be managed by a user interface layer, but I
think for getting the whole thing off the ground, it would be nice to
have a smooth, homogenous definition, which means it should be
explicit here.

[40:52]

Randy: it's the same crap in either case; it's just which of us bears
it.  I'm just trying to understand the tradeoffs. .... I don't know.

Ruediger: if Rob does it in the first place, it's going to be there
nice and clean for all time and all the users.  if it's not done
there, we don't know if it actually will happen.

Randy: the other way of thinking of it is "if Rob does the formal
check, that is it 3770 congruent, then we have a more formal nailing
to the floor". ....  asks about Kent's/Matt's code...

Matt: this actual code is written by another gentleman's who's not
here but our code is able to accomodate do to the efforts of Charlie.

Randy: so you guys are happy going either way?

Matt: yeah.

Rob A: I recommend taking this to the list; I think there are people
who have opinions who aren't present.

(off-microphone discussion)

Matt: I would like to get another version of the format draft out.  It
needs more reviews, but it's about ready for LC.

Sandy: in the arch draft, you said certain discussion of uses of ROAs
should move to the validation draft?

Matt: the validation draft... the scope does describe how one would
use ROAs in a transitional period to achieve better routing security
than we have today.  tere was some overlap in text in the architecture
doc.  I now say, ... please see roa-validation.

Sandy: do you believe that the validation draft adequently covers the
topics you removed from the architecture draft, currently?

Matt: [inaudible]

Sandy: could you look at that?

Matt: yes.  at a high level, the valdiation draft covers the topics I
think it needs to cover.  there's a question of do I agree with
everything Geoff says in the valdiation draft.  I don't want to be
signing my name...  the scope of the discussion in that draft is
appropriate and correct.

[44:30]

Sandy: names are required to be unique for a particular certification
authority.  i recall a long discussion of what CA....  when it rekeys,
it is removed from the requirement to maintain uniqueness?

Matt: the architecture draft is probably not sufficiently clear on
this point.  the answer is: yes, when the CA rekeys, we do need the
uniqueness to persist...

Rob A: details of this are very persnickety.  as I recall, we are not
rekeying a CA.  instead we are creating a new CA and destroying an old
one.  so, strictly speaking, the uniqueness requirement does not
persist.  technically, because of deep x509 voodoo, we're destrying
one and creating one.

Kent: ... the rekeying doesn't remove this requirement unless the NAME
changes.  ...  if the result of how we do rekey is that we change
name, then it's equivalent.  If you rekey w/o changing name, then you
still need to be unique.  ...

Matt: my action item for the next version of the architecture draft is
to clarify that name uniqueness is tied to the CA which is the NAME of
the CA. we can specifically mention that if rekleying changes the
name, uniqueness no longer needs to persist. ....  it needs to be said
well someone, and I will make sure it is.

David Cooper: if you follow X509...names are supposed to be globally
unique.

kent: but that's not reality, particularly for PKIs that don't require
structured names.

David Cooper: know of any examples?

[48:19 discussion redacted]

[51:15]  Steve Kent on CP doc

[1:00:45]  Steve implies that he's using MSWord for writing i-d's

[1:01:40]

Andrei Robashevsky

1) strip off references to applications (routing security and
transfers); stop with validation of claims
2) reasons for revocation may clash with policy or business practices;
move it out of this doc
3) terminology of CA may be misinterpreted

[1:03:40] Kent: #1 is easy; send details on the rest.

Randy agrees with Andrei re: #2 and goes into background re: RIPE meeting

[1:06:00] done with CP
[1:06:45} Geoff presenting on TA-00
[1:14:09] Q&A; long discussion
{1:33:00] process discussion
[1:36:15] more process stuff; ask WG re: adoption
[1:42:30] someone barks; examples of IANA/ARIN DBs differing 
[1:49:20] comments from Rob A generate clapping
[1:52:50] accusations of theft
[1:53:30] Dave Ward, outgoing AD

If you're going to include the technology, the last year's and
certainly the last hour here's discussion must be clearly written down
and discussed.  At the mikes and on the email list is not the way to
capture this information.

If you decide to preclude it, you have your answer: you have one trust
anchor.  If you decide to include it, you must discuss the pros and
cons because we will not decide the layer 9 issues in this working
group.  ...

Please decide whether you're going to preclude an entire scope of
engineering from the solution set.  [1:55:44] I recommend ... it's
almost impossible to preclude a solution set ... I'll leave it to the
WG to decide.

(unidentified speaker, off-mike) do other PKIs have to justify not
having multiple roots?

Ward: the pros and cons must be laid out.

Q: in other PKIs in the IETF, is this done?

...

[1:57:10] discussion of ROAs, BOAs and validation starts

Geoff: ... "my assumption ... is that the aim of the sidr work is to
allow the identification of bad routing information.  Not good; the
bad ones."

[1:58] Danny McPherson: withdraws support of BOA work.

Geoff: but would you agree re: aim of sidr work...

Danny: No; I believe that any useful security policy is explicit about
what should be permitted and implicit about what should be denied.

...

Danny: you're setting me up there, aren't you?

Geoff: yeah.

Randy: _AN_ aim of the sidr WG.

Geoff: minor quibble, but OK.

Randy: THE aim, as far as routing information goes, is to be able to
validate what is good

Geoff: well, no

shouted: yes

Geoff: we're trying to figure out who's lying

Randy: I'm trying to figure out who's telling the truth

(discussion of drinking, black & white, truth, etc.)

[2:00:00] Geoff presenting
[2:04:50] AS0 approach
[2:08:00] partial deployment
[2:08:30] ROA & ROA set semantics; completeness
[2:09:05] partial use; interpretation
[2:11:37] Ruediger Volk proposes an interp.

[2:14:20] Geoff: that's precisely what this slide says; ... we seem to
agree

[2:14:30] Rob A: I think I completely agree with the first one here; I
do not currently see a need for the second.  The second is as
inoffensive a way of expressing explicit denial as I can think of --
we get it for free.  If the people planning on stuffing this stuff
into routers need that, this is aplausible way to do it.  i would like
to hear from .. whether they want that capability.  I'm not currently
seeing it, but maybe I'm mssing something

[2:15:35] Randy: three things.  The AS0 hack was Steve Kent's inner
southern Californian trying to get out and make everybody happy.
... Second; the person writing code to put his in his routers keeps
looking down at this laptop. ...  Thirdly: he does have a draft out
there; it speaks to this very issue.  grep for pmohpat.  Essentially,
the first is correct, but...

The use case: I'm AT&T, I have 12/8.  John signs on as a multihomed
customer.  I give him 12.1/16.  His announcing that will be denied
unless either I, since I know he's lazy and he's my customer and
paying me, issue the ROA for him ... or he steps up to the bar and
publishes it himself.  Otherwise, if I have a ROA for 12/8, his
annoucement dies.

[2:17:40] Geoff: so what's the maxlen of your ROA?  ...

...

Randy: the specific can be announced by another AS...

Russ from Cisco: you now have two overlapping ROAs...

Randy off-mike.

[2:19:00]

Russ: the first paragraph on the slide I'm perfectly happy with ... my
only complaint about AS0 is that you're playing with magic numbers.
Magic numbers are bad things.

Randy: I agree. let's separate the two issues.  The common case I have
is I am 12/8; I say I am 12/8; I have a roa for 12/8.  But I also
delegation 12.1/16 to jason; I issue a cert.

Russ: what's your max prefix len?

Randy: it doesn't matter; there is no maxlen in a cert; I issued a
cert to him.

Russ: so...if you have overlapping ROAs; you check your cert on the
longer prefix ROA, and it valdiates, that's perfectly fine.  Your
other option is to not issue the ROA ont he whole /8.

Randy: no, because then the ROA for what Ihave left starts to looks
like chopped parmesean.

[2:21:40] Ruediger: ...

the AS0 hack lets you document whether you want to be the exclusive
source... or whether you leave it open.

[2:22:30} Rob: I think Randy is requesting that we stop calling this
AS0; as opposed to a magic widget.

Randy: re: terminology, syntax v. semantics

Geoff: Q: a prefix owner can indeed generate a ROA nominating any AS.
What is the semantic, in your view, of a prefix owner creating a ROA
with AS 0?

Randy: probably shouldn't be allowed.  But I'm with Russ White; it's
the syntactical issue; I don't like overloading the syntax.

Geoff: the semantics and syntax of the second sentence is consistent
with the first.

...

[2:24:08] Randy: I'd like to argue the semantics separately.

Geoff: Where I get confused...

Randy: ...

[2:25:47] Someone off-mike points out that the text on the slide
doesn't parse to the same thing people are saying.

Geoff: that's an editing mistake.  Assuming that this "unless" bit is
irrelevant.

...

Randy: I do not buy the "and no more specific"...

[2:27:12] Sandy makes a case for use cases.  Randy interrupts.

[2:28:34] Roque from LACNIC: what's the need for maxlen if you
delete...?  ...  Are we trying to characterize semantics of
issuance or what I should do when I receive a ROA?

Geoff: both

...

[2:31:23] Geoff: right now none of the documents are explicit about
what it doesn't say.  I produced a BOA that tried to be explicit and
folks said that was the wrong thing to do.  So we tried to be
explicit: when I create a ROA, I mean this.

[2:32:11] Randy: I'm willing to work with you on examples, Geoff.

Roque.

Dave Ward: you need to frame this as a selection algorithm.  In the
abstract terms you have now, it's hard to understand the results of
the algorithm.

Geoff: our brains work differently.

Dave: it's not what you're saying, it's how you're saying it. .... I
propose that in stockholm or on the list, perhaps with a presentation
of pradosh's draft, presented as a selection algorithm; let people
throw tomatoes. ...  Couch it in operational terms.

Sandy: I agree, but we also have to give instructions to
producers/issuers.

[2:35:10] Jason, defining terms.

[2:36:30] Randy, off-mike, would Jason be willing to issue ROA on
their behalf?  Don't know; have to think about.

[2:36:50] If I have a /16 and start making subdelegations, i don't
want to stat carving up my ROA --- I want to be able to say I own the
whole 16; there are more specifics, go use them.  That's how routing
works, let's make this work the same.

Randy: what he said.

[2:27:30] Danny: I see Geoff's point about clarifyng text. I think
that clarifying this text so that it removes the need for a BOA, if
possible, is a very good thing.

Kent: confused.  Jason: if you've got a chunk of addr space that's
been allocated to you and you have big chunks of it that have not been
allocated by you to any of your clients, are you saying you want no
mechanism whatsoever to be able to distinguish unauthenticated
assertions about that advertsiement?

(response inaudiable)

OK, that's what I thought I heard you said, so I think it needs to be
stated mroe clearly.

Jason: what I was trying to say was: if I get a /16 and I publish a
ROA for that 16 and I start makingg customer assignments out of that,
I don't want to be coming back to continually shrink what's
unallocated. ....

Jason: channeling Heather: she disagrees with my third point: if we
have an aggregate and some of our customers are using ROAs and some
aren't using ROAs, she thinks that should break.  She's more security
focused than I am.

Roque: you want this to work like routing today...

...

Sandy: asking for clarification

Geoff answers inaudiably.

[2:40:40] Danny agrees with Heather

[2:41:13] meeting ends