Subject: Re: [lamps] Recharter Discussion

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 12:25:28 -0400

I had already started a separated thread for discussion of the points Ryan
raised. Since this is about rechartering, it does not seem the right place
to discuss technology.

As a matter of process, if he is going to trash talk about CAs, I am going
to point out that those casting stones are not without sin.

I see the First Issued extension as being useful in S/MIME and not just the
Browser.

Of course a Linked Notary Log is always going to give the most accurate
source of truth, but only if you analyze it yourself. Otherwise you end up
relying on a third party that is not a CA. Also, consulting external
validation services has a cost, which is why browsers have been resistant
to Hard Fail on OCSP.

I see First Issued as an indicator that has the potential to be used for
triage. While I would like browsers to check revocation information on
every certificate, every time, that is not likely to happen soon. Offering
the option of checking if the cert is less than 7 days old seems to be a
control that would very likely be useful.

If CAs get the indicator wrong, I am sure Rob's tool will point out the
fact. That is how an accountability scheme works.

The biggest problem with any security control in this space is whether it
presents a real difficulty or if there is a simple countermeasure. Any
change we make is inevitably an experiment.

Of course we might end up implementing in CT. But that is a more complex
proposition as all the rules for construction and validation are going to
have to be worked out and fixed. A certificate extension is a simpler
approach.

Are people prepared to write drafts etc. explaining how to do this in CT
and submit them to TRANS? If not, the possibility of doing the job a
different way seems irrelevant.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Jul 2017 17:39:28 +0100

Hi Phill,

> have to be worked out and fixed. A certificate extension is a simpler

I'm not clear what's missing given [1] - can you explain?

Ta,
S.

[1] https://crt.sh/?q=down.dsg.cs.tcd.ie

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Jul 2017 09:54:26 -0700

On Fri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> ​Since Comodo distributes a browser, at least one browser is interested.
>

It seems like this indicator (and in fact any indicator which disfavors
recently issued
certificates) pushes in the opposite direction from design decisions we
have made
elsewhere which attempt to favor rapid certificate issuance. To take a
concrete case,
much of the structure of CT is designed around the premise that
certificates need
to be immediately usable. Were that not so, you could abandon SCTs entirely
and
simply have certificates contain inclusion proofs, which would obviously be
simpler.
So, having a system which was designed to make recently issued certificates
not
work seems to be opposed to the approach we have been taking so far.

Speaking from the perspective of a Firefox implementor, I don't really see
how we would
make use of this information in our certificate trust decision. We're
actually trying to
get away from making fine discriminations between different types of
certificates because
it's so hard for the user to make informed decisions, which means that the
only thing
we'd really be able to do is refuse the certificate, which I doubt we would
do.

-Ekr

Given that you seem entirely unconcerned by 16,000 fake paypal sites a
> certain CA has issued certs for, it is not surprising that you see no
> reason to make any changes.
>
>
>
> On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi <[email-masked]> wrote:
>
>>
>> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <
>> [email-masked]> wrote:
>>
>>> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell <
>>> [email-masked]> wrote:
>>>
>>>>
>>>> Hi Phill,
>>>>
>>>> On 29/06/17 17:54, Phillip Hallam-Baker wrote:
>>>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <
>>>> [email-masked]
>>>> >> wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >> On 29/06/17 16:21, Russ Housley wrote:
>>>> >>> Do others have an opinion?
>>>> >>
>>>> >> The function sounds useful but perhaps better provided
>>>> >> via an API to a CT log (not sure). The reason I'd wonder
>>>> >> about that is that it's hard to see what code would
>>>> >> read this new value and not want more information than
>>>> >> that. A CT log API could provide more so might be more
>>>> >> useful (e.g. if an RP could ask "show me your history of
>>>> >> meta-data related to certs for example.com").
>>>> >>
>>>> >> Probably not that relevant, but similar information would
>>>> >> also exist in passive DNS DBs I guess.
>>>> >>
>>>> >
>>>> > ​There is always a cut off between the standardized parts and the
>>>> rest.
>>>> >
>>>> > When I first proposed this, it was for human consumption. What I am
>>>> > thinking about now is rather more of a hook for likely proprietary AI
>>>> > systems reading it.​
>>>>
>>>> Right, that's why a CT API seems maybe more useful and (I think,
>>>> but I may be wrong), might be easier to get deployed.
>>>>
>>>> >
>>>> > ​Security is risk mitigation, not risk elimination. Right now we can
>>>> > eliminate what? 95% of phishing sites with free DV certs by simply
>>>> > rejecting any certs less than 5 days old. ​
>>>
>>>
>> Who is we?
>>
>> Is this a statement of what you believe browsers should do, versus will?
>> Have you heard of or can provide evidence for any expression of support,
>> from any browser, for this philosophy?
>>
>>
>>>> >
>>>> >
>>>> > ​What we do next with the ​data is going to be important. But not
>>>> something
>>>> > we are going to be able to really work on at all, let alone
>>>> standardize
>>>> > until after we have data.
>>>> >
>>>> > All I want to do right now is to instrument so we can start
>>>> collecting data.
>>>> >
>>>>
>>>> I'm not opposed to defining such a cert extension (which I
>>>> assume would be the end result) if there's likely to be
>>>> deployment. But I still think that given that CT logs will
>>>> have this info already, (and more, and covering >1 issuer)
>>>> a new CT API may be better than putting it in certs.
>>>>
>>>
>>> ​I don't really want to push everything into CT. This is not information
>>> that is going to be immediately available, you would have to do a lot of
>>> log crunching to validate.
>>>
>>> Given that some browsers won't do CRLs or OCSP, I can't see them using
>>> CT for pro-active checking before they accept the connection. Where I see
>>> the value of First Issued is to allow browsers to winnow out certs that are
>>> most likely OK and concentrate checking on those that might be a bit dodgy.
>>>
>>
>> Are you aware of any browsers interested in this? This feels very much
>> like LogoType - which was intended for browsers (among others) and
>> rightfully not widely implemented.
>>
>>
>>> At any rate, putting an extension into the cert is pretty simple while
>>> changing the CT API to support short lived certs is likely to be a
>>> performance. I think that this is an easy win to get much of the return and
>>> takes the pressure off the CT end of things.
>>>
>>
>> CT already has to deal with this. It does seem you're conflating two
>> unrelated things though, but perhaps I'm misunderstanding.
>>
>> Perhaps it could be useful if you could explain what you believe the
>> browser security model to be, and how this supports what browsers are doing
>> or have expressed support for.
>>
>> I do not see any value to this as an extension - and I can see
>> undesirable (and unreliable) data being added by CAs - so I'm curious to
>> understand why using CT is insufficient, especially for the proposed
>> browser-run machine learning reputation determination.
>>
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 14:08:07 -0400

I agree it is a bad idea for the user to be making distinctions. What I am
trying to do is to surface enough information for an AI to be able to make
a reasonable decision.

I also agree on the need for a rapid admin cycle, but that is not the same
as getting a site into production rapidly and start accepting credit cards
from the general public, do online banking, etc.

The problem I see the SCT scheme in CT addressing is to prevent the delays
in various parts of the system compounding so that 24 hours here, 48 hours
there, etc. ends up adding up to months.

The behavior I see right now is

1) Browser encounters certificate
2) Browser tells user that they are 'secure'
3) Browser performs validity checking via OCSP, CT, etc. to see if (2) was
actually true.

Now given that modern web pages are composite with content coming from
dozens of sources, even for relatively simple cases, the overhead for doing
validation is significant. And that is only going to get worse as the web
moves to 100% encrypted.

The problem is that encryption is not enough. Its like saying that the
armored truck you just handed the cash box containing $50K is secure
because it really properly armor plated, ignoring the fact that it is being
driven by the bank robbers. Authentication also matters.

What I am proposing as an option is:

1) Browser encounters certificate
2) Browser looks at First issued, other indications
    If certificate is recent, Browser performs validity checking via OCSP,
CT, etc. *before* telling the user they are 'Secure'.

Of course, not telling the user they are 'Secure' on the basis of a weakly
validated certificate would be a another way to address the problem, maybe,

Having the information inside the cert means that you have the option to
use it for triage.

On Sat, Jul 1, 2017 at 12:54 PM, Eric Rescorla <[email-masked]> wrote:

> On Fri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker <
> to be immediately usable. Were that not so, you could abandon SCTs
> entirely and
> simply have certificates contain inclusion proofs, which would obviously
> be simpler.
> So, having a system which was designed to make recently issued
> certificates not
> we'd really be able to do is refuse the certificate, which I doubt we
> would do.
>
> -Ekr
>
>
>
>
>
>>>> ​I don't really want to push everything into CT. This is not
>>>> information that is going to be immediately available, you would have to do
>>>> a lot of log crunching to validate.
>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 14:12:22 -0400

> [1] https://crt.sh/?q=down.dsg.cs.tcd.ie

1) ​The information exists in the certificate system if you know how to
look for it. That is not the same as the information being there in a form
that a robot can look for.

2) The information is not in the place where the decision to accept the
certificate as it is or to proceed without additional scrutiny is made.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Jul 2017 11:45:04 -0700

On Sat, Jul 1, 2017 at 11:08 AM, Phillip Hallam-Baker <[email-masked]

> there, etc. ends up adding up to months.

In discussions we have had about CT, being able to have the site itself up
in a matter of minutes has been cited as a high priority and thus a reason
why people needed to have SCTs. A system in which certificates aren't
acceptable for days -- or even have a high probability of not being
acceptable for days -- seems quite problematic.

> 3) Browser performs validity checking via OCSP, CT, etc. to see if (2) was

Which browsers are you talking about? This isn't consistent with my
understanding.

- For CT checking, I believe everyone presently relies solely on
information delivered by the server.
- OSCP handling varies a bit:
  - Some browsers (e.g., Chrome) don't do OSCP checking for most certs
  - When browsers do OCSP checking, they do it in the critical path but
with a short timeout and soft-fail for DV (EV is handled differently, but
most sites are DV).

> CT, etc. *before* telling the user they are 'Secure'.

I can't speak for other browsers, but I don't believe that we (Firefox)
would alter our OCSP/CT behavior
based on this indication, because OCSP/CT address other issues such as key
loss and CA misbehaviior.

-Ekr

>> Speaking from the perspective of a Firefox implementor, I don't really
>> see how we would
>> it's so hard for the user to make informed decisions, which means that
>> the only thing
>>>> Is this a statement of what you believe browsers should do, versus
>>>> will? Have you heard of or can provide evidence for any expression of
>>>> support, from any browser, for this philosophy?
>>>>
>>>>
>>>>>> >
>>>>>> >

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Jul 2017 19:13:58 +0000

There is more to PKI than the WebPKI.

I think that a CA being able to issue short-term certs, but saying "this same keypair has been bound to this DN for five years" is interesting and useful.  It could also bring new useful semantics to validating signed data that is old.

We already have one CA that has expressed interest in this.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Jul 2017 12:27:27 -0700

> There is more to PKI than the WebPKI.

Of course, though PHB's message seems to be explicitly positioning this as
for WebPKI (
https://www.ietf.org/mail-archive/web/spasm/current/msg00860.html).

I think that a CA being able to issue short-term certs, but saying "this
> same keypair has been bound to this DN for five years" is interesting and
> useful.  It could also bring new useful semantics to validating signed data
> that is old.
>
> We already have one CA that has expressed interest in this
>

Is there any interest from relying parties other than Comodo?

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Jul 2017 19:32:06 +0000

> Of course, though PHB's message seems to be explicitly positioning this as for WebPKI 

I didn't see it as limited, but more as an example.  Shrug.  Now we have two use-cases :)

> Is there any interest from relying parties other than Comodo?

Is there a quota of more than one?  Very well, if this extension were defined it is quite likely that the OpenSSL signature-verify tool would have an option to report it when the cert is expired since the data was signed.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 1 Jul 2017 12:05:22 -0800

Well, at any rate, an API is one of the pieces of work that's
already under consideration in trans.  I can see where having
that info in the cert might be more efficient (staple all the
things!) but I'm skeptical about the value of this given the
responses so far from people who actually build browsers.

If there's interest in this as a CT API use case, we'd
definitely be interested in talking about it - write it up
and let us know.

Melinda

---

From: Russ Housley <[email-masked]>
Date: Sat, 1 Jul 2017 16:16:50 -0400

Rich:

You seem to be arguing that renewal is interesting, and that a rekey would not maintain the same value for the first-issued extension.  I'm curious about your reasoning.

(I would have expected you to say something like 'I think that a CA being able to issue short-term certs, but saying "I've been issuing certificates for this subject name for five years" is interesting and useful.')

Russ

> On Jul 1, 2017, at 3:13 PM, Salz, Rich <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 1 Jul 2017 17:22:09 -0400

> 4b)  Updates to CAA for RFC Erratum 4514 (Phill)
> 
> HUM: Consensus in the room to suggest this for a future LAMPS WG charter.  Please propose a paragraph for the charter.

Please propose a paragraph for the charter on the mail list.

I's also like to spend a few minutes in Prague getting the language sorted.  The more that is done on the mail list in advance, the easier that will be in Prague.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 17:34:55 -0400

I already proposed the following four days ago:

X. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844

On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley <[email-masked]> wrote:

> > HUM: Consensus in the room to suggest this for a future LAMPS WG
> charter.  Please propose a paragraph for the charter.
>
> I's also like to spend a few minutes in Prague getting the language
> sorted.  The more that is done on the mail list in advance, the easier that
> will be in Prague.
>
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 1 Jul 2017 17:38:51 -0400

Yes, you did.  I was expecting some words to provide an understanding of the scope of the changes.  It should not be more than a sentence or two.

Russ

> On Jul 1, 2017, at 5:34 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> X. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844
> 
> On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 2 Jul 2017 00:55:05 +0000

> You seem to be arguing that renewal is interesting, and that a rekey would
> not maintain the same value for the first-issued extension.  I'm curious about
> your reasoning.
 
I am thinking about signed data, not the WebPKI.  Imagine I have a current cert and data signed before that cert.  Having an extension that said "this same DN and key were first good 'n' years ago" seems like it could help here.

> (I would have expected you to say something like 'I think that a CA being able
> to issue short-term certs, but saying "I've been issuing certificates for this
> subject name for five years" is interesting and useful.')

Shrug, that doesn't interest me. The browser will do its own validation in real-time.  I don't see how or why the WebPKI would find this useful.  But maybe I'm wrong, looking forward to what PHB writes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 21:48:57 -0400

On Sat, Jul 1, 2017 at 5:38 PM, Russ Housley <[email-masked]> wrote:

> Yes, you did.  I was expecting some words to provide an understanding of
> the scope of the changes.  It should not be more than a sentence or two.
>
> Russ
>

​I seem to recall some other people suggesting extensions to CAA to enable
their use in the issue process. But I can't remember who or where. I did
ping the CABForum list to see if they posted there. I also have to post the
final version of the errata, this has been checked by all the people who
objected previously without comment.

Unless additional work is proposed:

​X. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844.

RFC 6844 describes the mechanism by which CAA records relating to a domain
are discovered. Implementation experience has demonstrated an ambiguity in
the current processing of CNAME and DNAME records during discovery.
Subsequent discussion has suggested that a different discovery approach
would resolve limitations inherent in the current approach.

I am trying to be concise here... Can always make it longer.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 3 Jul 2017 11:34:42 +0000

Hi all,

For item 4a:

Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 functions) are the outcome of an open competition, unlike the previous hashing standards. They have a clear design rationale and have been receiving a lot of public cryptanalysis during and after the SHA-3 competition to today. All of that gives great confidence that the SHA-3s are very secure. The SHA3s also have much larger security margins than SHA-2s. In addition, since the design of the SHA3s is very different from SHA-2s (and other ARX-based designs), they offer sane diversity for security. Therefore, the SHA-3s are excellent alternatives for SHA2s.

Regards,

Quynh.

________________________________
From: Spasm <[email-masked]> on behalf of Russ Housley <[email-masked]>
Sent: Sunday, June 25, 2017 12:25 PM
To: LAMPS
Subject: [lamps] Recharter Discussion

We have almost finished the last document under the current charter.  We will beed to deal with any concerns raised by the IESG, but we should starts drafting the next version of the charter while that is happening.  In Chicago, we talked about several possible topics for the re-charter:

4c)  OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.  Unless someone else wants to step in, this one will be dropped.

4a)  Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
  LAMPS WG charter; however, a significant number thought it should not
  be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.  If you would like to see it move forward, please propose a paragraph for the charter.

Are there any other topics that someone would like to raise now?  All three of the above topics had at least one document to support them.  So, new topics should come with an Internet-Draft or a promise of one before the I-D cutoff for Prague.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 8 Jul 2017 13:24:33 -0400

Thanks.

Can you prepare a few slides for Prague.  Include the proposed text for the re-charter in the slides along with proposed milestones for two documents.

Russ

> On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi all, 
> 
> For item 4a: 
>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 10 Jul 2017 12:06:07 +0000

Sure,

I will make a few slides for the group to discuss at the meeting.

Regards,

Quynh.

________________________________
From: Russ Housley <[email-masked]>
Sent: Saturday, July 8, 2017 1:24:33 PM
To: Dang, Quynh (Fed)
Cc: LAMPS
Subject: Re: [lamps] Recharter Discussion

Thanks.

Russ

On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

For item 4a:

Regards,

Quynh.

________________________________
From: Spasm <[email-masked]<mailto:[email-masked]>> on behalf of Russ Housley <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, June 25, 2017 12:25 PM
To: LAMPS
Subject: [lamps] Recharter Discussion

Russ

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm