Subject: [lamps] RFC 3709

From: Russ Housley <[email-masked]>
Date: Fri, 17 Dec 2021 15:29:58 -0500

I have become aware that some people are begining to use Logotypes as defined in RFC 3709.

RFC 3709 says:

   The LogotypeReference and LogotypeDetails structures explicitly
   identify one or more one-way hash functions employed to authenticate
   referenced data files.  Clients MUST support the SHA-1 [SHS] one-way
   hash function, and clients MAY support other one-way hash functions.
   CAs MUST include a SHA-1 hash value for each referenced file,
   calculated on the whole file, and CAs MAY include other one-way hash
   values.  Clients MUST compute a one-way hash value using one of the
   identified functions, and clients MUST discard the logotype data if
   the computed one-way hash function value does not match the one-way
   hash function value in the certificate extension.

I'd really like to update the mandatory-to-implement algorithm to SHA-256.

That seems like this is the only paragraph that needs updated, plus a new reference.

Any concerns?

Russ

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 17 Dec 2021 22:39:36 +0000

Yeah, we noticed this a while back.  We support making SHA-256 the mandatory

to implement algorithm.

Corey and I can take a quick look and see if anything else needs to be
updated.

-Tim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Friday, December 17, 2021 3:30 PM
> To: LAMPS WG <[email-masked]>
> Subject: [lamps] RFC 3709
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Dec 2021 10:30:30 -0500

Please do this.

Can we also address the two HFDU errata while we are at it:
https://www.rfc-editor.org/errata_search.php?rfc=3709

spt

> On Dec 17, 2021, at 17:39, Tim Hollebeek <tim.hollebeek=[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2021 11:11:53 -0500

+1

On Tue, Dec 21, 2021 at 10:30 AM Sean Turner <[email-masked]> wrote:

> >> That seems like this is the only paragraph that needs updated, plus a
> new
> >> reference.
> >>
> >> Any concerns?
> >>
> >> Russ
> >>

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Dec 2021 01:34:20 -0500

Given that the IETF just stopped offering FTP, I wonder if we should also address this part of RFC 3709:

   All URIs MUST use either the  HTTP scheme (http://...)
   or the FTP scheme (ftp://...) [URI].  At least one URI in each
   sequence MUST use the HTTP scheme.  Clients MUST support retrieval of
   referenced LogoTypeData with HTTP/1.1 [HTTP/1.1].  Clients MAY
   support retrieval using FTP [FTP].

I'm thinking that we should drop FTP and require support for HTTP and HTTPS.

Russ

> On Dec 17, 2021, at 3:29 PM, Russ Housley <[email-masked]> wrote:
>

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Wed, 22 Dec 2021 14:57:20 +0000

> I'm thinking that we should drop FTP and require support for HTTP and HTTPS.

HTTP(S) for MTI. +1 

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, December 22, 2021 1:34 AM
To: LAMPS WG <[email-masked]>
Subject: RE: [EXTERNAL] [lamps] RFC 3709

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Dec 2021 16:35:52 +0000

Totally in favor of dropping FTP.

Would like to see HTTPS as MUST and HTTP as MAY, but willing to accept it the other way if the WG wants.

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Dec 2021 12:14:29 -0500

There is already integrity protection; the certificate extension contains the hash of the logotype.  So, no malicious party can swap the logotype at any point without detection.

Russ

> On Dec 22, 2021, at 11:35 AM, Salz, Rich <rsalz=[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2021 13:07:14 -0500

Agreed on integrity. But as we start to consider fixing the security
horrors of DNS rather than accepting them, there might well be a
confidentiality/traffic-analysis concern.

Right now, the leakage due to DNS dominates everything. But people are at
least starting to think about DNS traffic as a threat even if we haven't
got a practical solution yet.

Definitely not be enough for a 'MUST use HTTPS in the cert' but 'MUST
certainly support for resolution'. After all, it is unlikely anyone using
the logotype extension doesn't have TLS in their stack.

And some security considerations to the effect. We don't want to have to
revisit this down the line.

On Wed, Dec 22, 2021 at 12:14 PM Russ Housley <[email-masked]> wrote:

> There is already integrity protection; the certificate extension contains
> the hash of the logotype.  So, no malicious party can swap the logotype at
> any point without detection.
>
> Russ
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Dec 2021 12:50:02 -0500

Russ Housley <[email-masked]> wrote:
    > There is already integrity protection; the certificate extension
    > contains the hash of the logotype.  So, no malicious party can swap the
    > logotype at any point without detection. 

I don't have any experience with RFC3709.

I have been often frustrated trying to update systems that have expired trust
anchor stores,  obsolete (SHA1-only-infestation) software, and the like.
The push towards HTTPS-only (particularly for objects which have internal integrity
already) has often meant that I've had to do manual things to make get things
updated.

My limited understanding is that 3709's logotypes is an input into certificate
acceptance, and it seems that if they are available only via HTTPS that there
could well be a circular trust problem.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Dec 2021 12:52:11 -0500

> the logotype extension doesn't have TLS in their stack.

Unfortunately, we don't have a URL scheme that says, "do some privacy", but
don't force authentication.  if we did, then I'd ask for that.

And while we might the *right* TLS stack (the one with TLS1.3...), we might
not have the right anchors.  But, as I said, I don't know enough about how
3709 is really used.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 23 Dec 2021 22:21:45 -0500

> could well be a circular trust problem.

No, logotype has no bearing at all on the trust evaluation or acceptance.
It’s wholly independent, unlike, say, AIA, OCSP, or CRLs, which would (and
do) have the issue you highlighted. Even still, that issue is not
insurmountable; while Windows prevents HTTPS fetches of specifically those
resource types, recent versions of MacOS/iOS explicitly default to HTTPS
for such fetches.

In any event, for logotype, because it is a supplementary resource used
post-validation, there are no obvious interop or trust issues from making
HTTPS MTI.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2021 22:51:24 -0500

> post-validation, there are no obvious interop or trust issues from making

Reading the above, it occurred to me that we have been going at this
slightly wrong because:

https = MUST use TLS to connect.
http = use http over transport protocol whatever

The https scheme forces use of TLS but there has always been this idea that
http should opportunistically upgrade.

So to be really pedantic, we should be saying TLS transport is MTI.

Not that I expect it makes any real difference because I can't see folk
using logotype certs not having TLS in their stack. The only reason they
might not is if there was an alternative transport security enhancement.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Dec 2021 10:31:47 -0500

> post-validation, there are no obvious interop or trust issues from making

Thank you for the reassurance.
I've never experienced logotypes... I guess I'll search youtube for a
screencast where someone is interacting with one.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carl Wallace <[email-masked]>
Date: Fri, 24 Dec 2021 10:42:53 -0500

If you do set out to experience logotypes first hand, watch out for the LogotypeScent variety.  /s

On 12/24/21, 10:32 AM, "Spasm on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Dec 2021 18:27:44 -0800

> So to be really pedantic, we should be saying TLS transport is MTI.

That is true, but ... we just changed the status of RFC 8164 (opportunistic
security for HTTP/2) to Historic because no one was using it.  So it
probably is just a pedantic distinction, at least for now.

-Ben