TRANS WG
co-chairs: Melinda Shore and Paul Wouters

Paul: blue sheets, please sign
Paul: Note well, please read
Paul: Agenda bashing

Eran Messeri presenting http://www.ietf.org/proceedings/91/slides/slides-91-trans-5.pdf

Ryan Sleevi: (in response to item 42)
redacted certs ties to EV. DV have little restrictions in name wildcards,
loose restrictions. any subdomain you want.  EV does not allow wildcards,
and there is a series of checks they need to check a high risk registry
defined in cabforum, name collision etc. with respect chrome policy,
we want to be able to audit to see if you issue an wildcard EV, breaking
the guidelines.

We support redacted name solution for DV. For EV and initial deployment we
are not keen. We would bounce wildcard with EV.

What is the issuance policy behind [the redacted cert]

Paul: what do you want? more text?

Ryan: it might help to provide clarification with cert redaction in the text,
for example in security considerations section. Does policy X allow
name redaction?

Eran: number 28 Algorithm agility. This issue was raised by Stephen Kent.
Perhaps he can clarify this issue? [Steve was not there]

Eran states Stephen Kent has started a threat model and security analysis
document.

Melinda corrects him that she believes he did not. We have not yet decided
if this should be split in a separate document.

Paul presenting Ben Laurie's presentation:
http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf

Leif ?? You need to allocate the OID somewhere. IANA will sort this out.
Leif ??  leave it as TBD and leave a note for IETF in the draft.

Paul: Signed certificate time stamps. Ben suggests using TLS structure.
      Does anyone mind or have input?

[no one speaks out]

Paul: We will bring this to the list for more discussion

Steve Kent: since two of the three formats are ASN.1 why use TLS?

[ various people say because ASN.1 sucks ]

Paul: Client behavior: should 6962bis specify client behavior?
Paul: The chairs believe it is better in a separate document.
Paul : There is quite some text Steve Kent proposed for the main document
        but we think it is better to put it in a separate document. It should
        not affect the auditor or the log. It could be a local policy and
        different clients could use different policies.

Daniel Kahn Gillmor (DKG): Specifying client behavior in 6962bis seems
extreme and will probably be wrong until we get more experience. I'd like to
see us specify the different types of failure we expect to see so that
further drafts can refer to specific circumstances. We might not want to
define what the behavior is because that may change, it would be useful
to catalog the kind of scenario's the client may find itself in.

Paul Hoffman: to add on to that: Not only list them but give them
individual names. so that when we have the later discussion so these
are clear.  if a client is expecting X and does not get it, it should
consider it a security situation. We might have 5 or more named, but
we will not specify what the client should do. That can be expanded in
other drafts. That could literally be in an appendix.

Steve Kent: if google mandates client behavior for EV for chrome,
why does it not belong in 6269bis?

Paul Hoffman (and others): We are not google

Ryan Sleeve (Google): UI requirements are promptly removed by browsers. we
strongly recommend not putting UI requirements in documents. Hard-fail
or OCSP has been a problem. Had that been mandated, in reality it would
not have worked. Going too far on mandating behavior will cause it to
be ignored and will just be confusing to people reading the spec.

Wes Hardaker: I suspect what Steve is looking for. how you present an
error in a UI is a totally different notion than what you do when you
get there.  Some browsers might throw out errors. Our documents use the
words SHOULD and SHOULD NOT extensively to describe what we as a community
believe what we think it should do in certain error conditions. I think
what Steve wanted to have in the document for example is that [this]
happens we stop the connection or if [that] happens we don't. Or in this
one it is up to local policy. Even if it is a UI issue it is still a
protocol issue.

Paul Hoffman: I strongly disagree we are the "you must stop the connection
[xxxx]". Whatever document should clearly define the states. I don't
think we will have consensus in the room on when to break a connection
based on a set of data processed by a set of people.

Steve Kent: if there is no mandated TLS client behavior note the
implications for the attack analysis, i.e. we lose most of the arguments
of what CT does with regards to addressing mis-issuance.

PHB: plus one on Paul Hoffmann here. We don't know which CA's bought
into a particular PKI.  It might not be WebPKI. It might be email. If
we decide on one set of client behavior we are restricting our selves
to a connection breaking behavior. don't limit ourselves with a mandate.

Aaron Missere[sp?]: I support [Paul Hoffman]. We should enumerate possible
states rather than specify behavior. The state is in indicator to the ui

Wes: If we want to put it in a separate document that's fine, but I
disagree that we don't say when we break connections.  We don't do PKIX
and say if validation fails do whatever the heck you want. That just
does not fly.

Steve Kent: WebPKI is the only current context for the spec. 

[chairs wonder if that is right]

Paul Hoffman: WebPKI was defined for another group and that group has a
very different vision of who was or was not in the WebPKI. I don't think
we bought into that here. Here we thought about TLS and most TLS is used
in browsers, but we didn't bought in to the WebPKI which is a set of CA's
who all volunteered to follow certain rules. I am hoping this is NOT the
WebPKI. And that it follows those CA's that haven't volunteered to these
rules or have gone rogue. There are a lot of CA's not on the CABforum
and I want to follow those CA's more than the ones in the CABforum.

Melinda: i looked at the charter, it does mention TLS (http over tls)
[but not WebPKI]

Paul: it seems there is some sort consensus on describing a list of common
error conditions and we should go back to the list and see how we can
define a set of limiting client behavior or obvious client behavior
and see what we do with the ones we cannot agree on. I think Ben also
agrees we cannot enumerate all of them.

DKG: It's fine to say there are scenario's where we don't know what to
do. If there are scenario's where it is clear what to do why shouldn't
we say what to do [example with EV cert and name redaction]

Stephen Farrell: Are we walking into a hard-fail lamp post? Browsers don't
hard-fail, so it is hard to spec failure cases without assuming browsers
do hard-fail. [he does not want the working group to get bogged down]

Jeff Hodges: We've actually crossed this bridge once before. In the HSTS
spec RFC 6797 in section 12.1 in user agent implementation considerations,
geez, if you get an error on TLS establishment you should really close
the connection and not give the user another recourse for the following
reasons ....

Ryan Sleeve: there hasn't been push back on EV redaction from this room
or the list but there has been significant push back from CA's. Even
something that seems as simple as [this doesn't have consensus without
significant push back] The ugly thing of browsers is that everything is
becoming local policy to decide. Yes, enumerate security considerations,
but the MUST/MUST NOT language is going to be shaky

Paul: I guess the working chairs will see which discussions cannot get
consensus and those will be kicked out of the document.

[continue discussion on name redaction slide]

Paul Hoffman: I'll admit confusion. I thought the name redaction was done
in the log itself? Are there logs where the name is already redacted? If
so, then this is more than just client behavior

Steve Kent: If we are omitting name redaction in 6962bis we are not
addressing what we are told is an important issue for CA's

Ryan Sleeve: Name redaction is not in the log and for the CA cases that
we heard there is a strong desire not to have name redaction in the
log. These logs are untrustworthy and CA's cannot reveal these. Name
redaction happens in the message send to the log by the CA or whomever
submits it. So I think 6962bis should describe how name redaction is
going to work. the log has to decide what to accept or not. Redacted names
might change log behavior. Log policies differ per organization. google
will only accept certificates that map back to one of a known set of
CA's. Other logs might only log certificates from their own CA. There
might be a log out there that only logs EV certs and this might refuse
any certificate with name redaction. 6962bis definitely needs to specify
how to do this.

Eran: logging name redacted certs seem to be usable for deployment of
DV certificates. I agree with Steve Kent's point about addressing issues
CA's have raised.

Leif: Could this be split of into a separate document? Why mix this up
with the core document?

DKG: It also has to do with how monitors will work and how clients can
verify certificates with the SCT's. It touches all the actors in the
eco system with the exception perhaps of the logs.

Leif: Ah yes, you are right. Never mind what I said.

[ Paul attempts to get a minute taker and fails ]

Stephen Farrell: Why by next IETF? [Melinda expects he means: why not
sooner?]

Paul presenting for Linus Nordberg on gossip:
http://www.ietf.org/proceedings/91/slides/slides-91-trans-7.pdf

Paul: scaffolding work. Mostly interested in hearing if people agree
with the split of these documents or whether people feel these should
be merged into fewer documents.

Paul: documents could use some help too. If you want to help, let us know

DKG volunteers

Paul: the first three documents on message format, transport protocol
and gossip protocol need to see more work before we can talk about client
strategy and policy.

Linus: should we really do that - the fourth issue of specifying strategy

Paul: Let's postpone that discussion for now until the first 3 documents
have more content

Dacheng Zhang presenting CT for DNSSEC:
http://www.ietf.org/proceedings/91/slides/slides-91-trans-3.pdf

Wes Hardaker: Go back a slide or two.... Assuming that you do things
like put a DS record in a log so you cannot generate a fake DS to a
fake child, CT becomes somewhat useful because you're logging all of
the supposedly published records. The problem is that it just moves the
attack scenario to an easier one. The parent can generate records for the
children directly and sign it with their own key. The client asking the
question has no idea where the zone cut is, so i can ask what the A record
is for www.example.com and I can ask it to the root or to com, and .com
tells me it is this or that and it won't even delegate it to example.com
in the fist place.  The DNS tree is already very trusting from the top,
if you do not trust your parent you cannot use your parent. .com is
prohibited from putting such information in, but there is nothing stopping
it from doing so, AND all the software today already supports the notion
of split-view DNS. It can return different data to different clients.

PHB: I agree. If you are interested in this, you don't want to trust the
DNS from the top down, and you curate data on your own DNS client and use
this as an input to this curation function.  There is a use for trans with
DNSSEC but it would be DNSSEC-2 which would change the trust protocol.

Paul Wouters (not as chair): I had similar problems with this but it
still useful to log this, and I was thinking to use the CDS record,
since that is signed by the [child] so you know it is what the [child]
believes is the real DS record. The CDS is a copy of the DS record in
the child zone. The problem there is if the parent legitimately takes
away the child zone and re-delegates it how do you distinguish these
[from an attack].

Wes: you want to log both. You are right, you do not know if the parent
is evil or the child did not pay for their zone. This is why you want
a log. You have a lot of bells but not a good notion of what to do.

Paul: That is the same issue as with certificates themselves. If someone
takes that domain there is also a [now] illegitimate certificate.

PHB: to give a concrete example here, if you remember vb.ly, it was a
shorting service that was re-taken by the government. I want to resolve
it to the publisher of the original data, not the current owner of the
domain. The trust is about that I am going to the place I intended to
go to. Like Wes said, it might ring an alarm bell, possibly not on my
cell phone, but perhaps in the Symantec or Comodo head office...

DKG: I agree with the idea that this is why we want a log. Even if
the enduser cannot do anything about it, but the operator still wants
to know. If they cannot tell the infrastructure is weak. Parent zones
need to be held to a higher standard of accountability because of the
centralized model of trust. But there are concerns about log spam. With
certificates that's easier. In DNSSEC it is easy to fill up the logs
and I don't know how to address that.

Wes: Just realized that if you are holding your parents to a higher
standard they can still work around any CT problem in the first
place. Parents can always lie and the log does not help you. The log can
still help.  Who do you ask when there is a discrepancy. For example,
I gave up a domain this month. It is legitimate that the new owner put
up a link spam page. It is legitimate. Someone looking at the log and
wondering why the DS record went away (it is now not signed) they have
no notion of who to ask or where to go to.

DKG: if the parent has to log the records it serves. [...] if you can
monitor everything that was signed by that parent zone you can find that
they have been serving A records for your domain and something fishy is
going on.

Paul Hoffman: I partially agree with Wes but I do not think it is that
bad. The philosophical difference between CA's and DNS is split-DNS. If
you do that carefully, whoever you are trying to hand this to can only
see that.  For DNSSEC, you really are only going to monitor the large
zones that people consider of high value, which comes down to the
question of spam. Theoretically, sure there could be a lot of spam but
that's not what people really care about. And the person who is keeping
the log is only keeping it for things that are interesting. The people
keeping the logs will have monitors in many places so a split-view DNS
[will be revealed]. For the idea of "my parent just messed me up on
purpose", these logs will be fine.

Wes: as I had mentioned, I think logs are useful. It is not 100%
attack proof. In the security sections this should be mentioned. That's a
perfectly safe thing to do for an RFC. In DNS things change every time. In
.com its SOA changes every few seconds. The logs will be ginormous

Paul Wouters: This is why we want to limit the log to DS records or the
like and why we would demand a minimum signature life time and what not.

Wes: But this was in response to "we need to log everything" so .com
cannot lie about www.example.com, so the DNS tree is kept in the log
for perpetually or eh ever. That's operationally very challenging.

DKG: If we cannot log the actual records served by the parent zone. Then I
agree it does not provide much benefit at all. Maybe [interesting] zones
we want to log have constraints in what sub-records they can serve. So
.com can serve DS records and glue but not other stuff. Not sure if we
can take advantage of that.

Paul: but we are trying to defend against these parents lying, we cannot
trust them to not serve some records.

DKG: we need to address this. This is centralized control that
is not properly accountable. We should not drop it and say it is
unfeasible. Perhaps zones need to opt-in to be constrained in a way. Maybe
that means publishing not just your DS records but everything.

Allison Mankin (versign labs): CT seems a good candidate for publishing
trust anchors that you could use rather than going all the way up to
the root. And log only those trust anchors and not everything in the DNS.

Paul Hoffman: DKG you are wrong. We only need to capture data that was
signed in a way we did not expect.  That's why we are looking at the
DS record. If they were signed it was either by the one the child zone
wanted or it is not and than we are going to know that. DS records don't
change that often.

[so how do we deal with the parent publishing something beyond the
zone cut]

Paul Hoffman: They have to do that in a way that is signed. So it is
detectable.

Melinda: touching on next steps, I haven't discussed this with Paul so
this is just me. There are a couple of questions. One is assessing level of
interest and the other is coming to an agreement on content. Right now
I think we need to focus on getting the 6962bis document out so we are
looking at another iteration of that before we start looking at working
group adoption [of the DNSSEC document]. It is certainly engendered a lot
of discussion and there is clearly an interest. We need more discussion.

Dacheng Zhang presenting CT for Binary Code
http://www.ietf.org/proceedings/91/slides/slides-91-trans-2.pdf

Paul: you only logging the signature, not the file size?
Dacheng: the file is maintained in the log.

Christian Witteman (Microsoft): I'd like to understand the attack you
are worried about. The main attack we see is forged certificate. but
you seem to be worried about the code manufacturer themselves issuing a
[rogue] binary signed with their certificate?

Dacheng: customers might wonder why they are getting different firmware
from vendor compared to other customers.  CT allows vendor to say we
published firmware to everyone that is the same for everyone.

Christian: the certificate is attached to a name, and we have certificates
because the code does change all the time.  What is unclear is the
relation between certificate, publisher name, etc.

Linus Nordberg: publisher of binaries might have their build systems
owned, or their keys compromised. Helping them find out about that
is helpful.

Dacheng: compromise of key is out of scope.

Ben Kadok[?]: there is software out there where distribution is limited
and you won't be able to put the full binary in the log without violating
the license terms.

Dacheng: Maybe in the future that could log only the digest of the
software? I am thinking about that.

Seth Schoen of the EFF: I wanted to defend the usefulness of this work
in what I think are two different scenarios.  one is where the signer
does not realize that their keys have been compromised. If their update
system requires using a CT log than they could find out about their
compromise. The other case is where a publisher or users of the software
are concerned about a co-ercion attack against the publisher to sign
software that is not in the interest of their users, and I think this
work is very relevant potentially to deter these two classes of attacks.

DKG: I think the mechanism as described would not work for some free
software distributions that I think would be happy to have that kind of
supervision that Seth was describing on their signing keys so i would be
interested in trying to help figure out how to make this type of approach
something that would be useful for free software distributions that want
to be held accountable.

Paul: can you explain what does not work for you?

DKG: I think that concrete . uhm pieces in here that assume X.509 as
the certificate hierarchy. I know that Debian at least uses openpgp
signatures across manifests that themselves have digests in them. There
may be technical tweaks that need to happen.

PHB: it will be useful for the binary signing to be standardized so
it can be used across the entire industry because at the moment
every single platform has a different way of signing. Even the ones
using X.509 all use it in slightly different ways. If you look at the
difficulties developers have to get certificates you have to go and get
multiple certificates for java and windows and it is stopping people
from singing. I want to get where everything is signed, even a trial
build should be signed. Everything should be signed so we can track
it. We like to track the good stuff, not the bad stuff.

Ryan Sleeve: I just want to quickly disagree with PHB about the x.509
unification, that's wind mill to tilt at some other day because
every browser already has different root programs for very intentional
reasons. They have different policies and the idea that a single
certificate be used across multiple software products like java or
flash is a whole different world of policies and we all know that policy
discussions are a way for entire working groups to disappear. But I do
want to say that there certainly is an interest like DKG was saying in
figuring out a way assuming X.509 submitting the full software instead
of a hash, to echo [someone] you could potentially integrate with chrome
safe browsing so whether a binary has been seen could be used for malware
detection separate of product updates. Very interesting, and I know Ben
Laurie has been talking about for a while, there is interest.

Paul: as with ct-dnssec, we will pick this up when our core documents
are in good shape

PHB presenting compressed CRLs:
http://www.ietf.org/proceedings/91/slides/slides-91-trans-6.pdf

Paul Hoffman: you said these are the hashes on the certificates? But
the hash of any certificate is going to differ on every single bit?

PHB: We take taking millions of them and sorting them [so there will be
lots of similar bits]

Paul Hoffman: that would only be if your list was 2^69 bits long? If it
is only a million you will have a lot of bits different.

Yoav: which hash are you using?

PHB: Its not critical, but it is SHA2. 

[audio archive cut off here]