Subject: [Trans] IETF 90 scheduling

From: Melinda Shore <[email-masked]>
Date: Mon, 21 Apr 2014 14:35:39 -0800

We just received notification that working group session
scheduling for the July meeting is now open.  This is a good
time to be thinking about what needs to be done between
now and then and how session time will be spent.  Right now
my sense is that a single two-hour session will be more than
enough, but I'll hold off until we get a better sense of
what will need to be done during the session.

Melinda

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 23 Apr 2014 16:51:07 +0200

Hi,

I have actually two technical comments with the current specifications of
CT:

#1 Log server identification

Currently, if I am correct, the identity of the log server providing the
SCT is based on its public key (in fact, the hash of it), which is also
stored in the TLS client. As with the public key pinning mechanism (cf.
draft-ietf-websec-key-pinning), I am afraid about a potential complexity
(from a technical/business point of view) to add a new public key in the
TLS client (e.g., web browser), to be able to set up/manage a new log
server.

So, I am wondering, instead (or in parallel) of using log server's public
key as log server's ID, if that would be easier to use URI for new log
servers deployment.

#2 Interaction between TLSA RR and CT

At first, from my point of view, using TLSA RR means "prevention" and using
CT means "repression". Now, if I want only do "prevention", the current CT
specifications will not allow me to do it. Indeed, as specified in Section
3, TLS clients MUST reject certificates that do not have a valid SCT for
the end-entity certificate, enforcing the use of CT by the TLS server.

Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would
relax this enforcement.

I would appreciate any feedback from the WG regarding these comments.

Thanks in advance for your replies.

Best regards,

JMC.

2014-04-22 0:35 GMT+02:00 Melinda Shore <[email-masked]>:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Ben Laurie <[email-masked]>
Date: Thu, 24 Apr 2014 15:51:59 +0100

> key as log server's ID, if that would be easier to use URI for new log

There's already been a fairly extensive discussion on this, perhaps still
not resolved. But my position continues to be that the TLS client needs to
know various things about the log - public key, URL, MMD. I don't see the
problem in those things being communicated in a data structure (e.g. in
JSON).

Indeed we will shortly be defining such a structure for Chrome's valid
logs. Whether this should form part of the RFC is up to the WG.

> At first, from my point of view, using TLSA RR means "prevention" and
> using CT means "repression". Now, if I want only do "prevention", the
> current CT specifications will not allow me to do it. Indeed, as specified
> in Section 3, TLS clients MUST reject certificates that do not have a valid
> SCT for the end-entity certificate, enforcing the use of CT by the TLS
> server.
>

That is correct.

> Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would

No, because this gives an attacker a way to evade CT.

-- 
Certificate Transparency is hiring! Let me know if you're interested.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Apr 2014 10:56:41 -0400

Ø  There's already been a fairly extensive discussion on this, perhaps still not resolved. But my position continues to be that the TLS client needs to know various things about the log - public key, URL, MMD. I don't see the problem in those things being communicated in a data structure (e.g. in JSON).

.. and crypto mechanisms being used. At IMHO, this is not resolved.

Ø  Indeed we will shortly be defining such a structure for Chrome's valid logs. Whether this should form part of the RFC is up to the WG.

Yes, at least there.  I think the structure should be embedded in the log’s root, for simplicity of deployment evolution, and aiding after-the-fact auditing.

                /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]<mailto:[email-masked]>; Twitter: RichSalz

---

From: Rob Stradling <[email-masked]>
Date: Thu, 24 Apr 2014 16:00:36 +0100

"the log's root"?  Root certificate?

Each log has a raw public/private key, not a root certificate.

Or do you mean something else?

On 24/04/14 15:56, Salz, Rich wrote:
> ØThere's already been a fairly extensive discussion on this, perhaps
> still not resolved. But my position continues to be that the TLS client
> needs to know various things about the log - public key, URL, MMD. I
> don't see the problem in those things being communicated in a data
> structure (e.g. in JSON).
>
> ØIndeed we will shortly be defining such a structure for Chrome's valid
> Yes, at least there.  I think the structure should be embedded in the
> log’s root, for simplicity of deployment evolution, and aiding
> after-the-fact auditing.
>
>                  /r$

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Apr 2014 11:01:19 -0400

The root block of the tree.

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Apr 2014 14:02:38 +0100

> The root block of the tree.

Hmm. I don't really object to that. How would we identify the logs to
clients in your scheme? It seems to me that logs should be allowed to
change their URL (not recommended, but possibly could be needed), so the
URL doesn't seem like a good identifier.

We need something that allows clients to gossip so they can verify that the
parameters they see in the root are as expected.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Apr 2014 09:25:10 -0400

Ø  Hmm. I don't really object to that.

Huzzah! Time to recall  heartbleed as an attempt to wear you down ☺  (Too soon?)

Ø  We need something that allows clients to gossip so they can verify that the parameters they see in the root are as expected.

Something in URL syntax to identify the log, even if it’s not the actual URL?  Like an XMLNS string?

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Apr 2014 14:41:05 +0100

On 25 April 2014 14:25, Salz, Rich <[email-masked]> wrote:

> Huzzah! Time to recall  heartbleed as an attempt to wear you down J  (Too
> soon?)
>

;-)

>
>
> Ø  We need something that allows clients to gossip so they can verify
> that the parameters they see in the root are as expected.
>
>
>

Hmm. We already have three ways to structure data. Do we need to introduce
XML, too? :-)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Apr 2014 09:43:16 -0400

Ø  Hmm. We already have three ways to structure data. Do we need to introduce XML, too? :-)

No, I just meant a URI string that might not be dereferencable.

Is it too onerous to say that if a log’s URL changes, then a new log must be created?

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Apr 2014 16:21:02 +0100

> Is it too onerous to say that if a log’s URL changes, then a new log must

Maybe not.