[lamps] Paul Wouters' Yes on draft-ietf-lamps-rfc3709bis-08: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-lamps-rfc3709bis-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc3709bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Sec AD review of draft-ietf-lamps-rfc3709bis-08

CC @paulwouters

Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

This review uses the format specified in https://github.com/mnot/ietf-comments/
which allows automated tools to process items (eg to produce github issers)

Like Warren, I had an "OMG" moment, but then also realize it is a bis document
:-)

Going through the changes, I appreciate the attention to privacy and security
that were added. I just have a few comments.

## Comments

### svg+xml vs svg+xml+gzip

I find it a little odd that support for svg+xml is SHOULD and svg+xml+gz is
MUST, as clearly if you support the MUST you have all the parts to support the
SHOULD. Also, it makes me a little nervous to have to have gzip support in this
security function, as we have seen lot sof dangerous vulnerabilities in
opensource decompression library functions.

### Why not register image/svg+xml-compressed media type
```
        NOTE: The image/svg+xml-compressed media type is widely implemented,
                           but it has not yet been registered with IANA.
```

Why does this RFC not register it?

### usage or install of cert?
```
       Further, when logotype data is not cached, activity on the network
        would reveal certificate usage frequency
```

Is the usage of logotypes to be expected every time the certificate is used? Or
only when the certificate is "human checked" for installation? I would think
when installing a VPN cert, that I would see the logotype when installing the
cert, but not every time I bring up my VPN. So I think the "certificate usage
frequency" is not necessarily leaked as this sentence claims.

### DoT
```
       In addition, the use of an encrypted DNS mechanism, such as DoT
        [RFC7858] or DoH [RFC9230], hides the name resolution traffic
        associated fetching remote logotype objects.
```
It hides it only from third party observers. A malicious (or nosy) CA
can still see all the DNS traffic as they will point it to their authoritative
DNS servers. So encryption to these servers doesn't hamper them seeing things.
So I think this claim needs to be updated to state "third party people cannot
see DNS when using DoT".

### SHA1 in example use
Seems a bit lazy to keep the RFC 3709 certificate unchanged using SHA1 when the
document drops SHA-1 as the mandatory-to-implement hash algorithm :P