Re: [Uta] [TLS] OCSP in RFC7525bis

2022-02-01 Thread Hubert Kario

On Monday, 31 January 2022 21:18:52 CET, Ryan Sleevi wrote:



On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario  wrote:

Browsers are the only software that use browser's implementation of 
certificate

verification and revocation.

And while they are significant users of TLS, they're definitely not the
only important users of TLS.

In the context of the thread, it’s hopefully clear I was not 
trying to argue they are the only important user, but rather, a 
demonstration of a practical alternative to deliver this 
information. 

That said, on platforms like Apple’s *OS family (mac/i/tv), 
and, to a lesser extent, Windows and Android, such distribution 
_is_ system wide, and TLS-using applications, including 
non-browser, don’t need to take any special action.


I'm not aware of any OneCRL-like functionality in Windows...
Do you have some pointers for that? Or are you talking just about the fact
that Windows downloads and stores CRLs system wide?

It’s really only in Linux that there isn’t some form of 
system-wide capability available, and although Linux remains a 
significant in this space, it shouldn’t be used to preclude more 
holistic approaches.


The CA store used by OpenSSL as the -CAdir or X509_LOOKUP_hash_dir[1]
can store CRLs too, making sort-of system-wide certificate revocation
without need of OCSP possible too (NSS also supports a system-wide CRL 
store,

I think only GnuTLS doesn't).

1 - 
https://www.openssl.org/docs/man1.1.1/man3/X509_load_cert_crl_file.html


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-31 Thread Ryan Sleevi
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario  wrote:

>
> Browsers are the only software that use browser's implementation of
> certificate
> verification and revocation.
>
> And while they are significant users of TLS, they're definitely not the
> only important users of TLS.


In the context of the thread, it’s hopefully clear I was not trying to
argue they are the only important user, but rather, a demonstration of a
practical alternative to deliver this information.

That said, on platforms like Apple’s *OS family (mac/i/tv), and, to a
lesser extent, Windows and Android, such distribution _is_ system wide, and
TLS-using applications, including non-browser, don’t need to take any
special action.

It’s really only in Linux that there isn’t some form of system-wide
capability available, and although Linux remains a significant in this
space, it shouldn’t be used to preclude more holistic approaches.

>
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-31 Thread Hubert Kario

On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote:



On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor 
 wrote:

This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT".  Why would a
client deliberately fail a connection when the problem might be a flaw
with an unrelated network service or a client-specific routing failure?

I think we can definitely explicitly recommend:

 A) clients MUST require valid stapled OCSP response when encountering a
certificate with "must staple" extension.  (this is just following
the specs, but i don't think it's as widely supported as it should
be; maybe we need some public naming/shaming?)

Isn't this also a "MUST, BUT WE KNOW YOU WON'T AND PROBABLY SHOULDN'T"?

There are good reasons that clients have not, and potentially 
will never, support Must-Staple, whether it be for the technical 
reasons that many servers are unfit to support it, or for policy 
reasons, such as wanting to be careful about the security 
policies of their products, and how much of that is outsourced 
to CAs. The choice about whether to require stapling or not _is_ 
a policy decision relevant not only to server operators, but 
also relying parties, and can be easily abused by CAs if given 
that lever. Given the concerning practices already seen with 
respect to revocation, which are detrimental to the security 
goals of both server operators and end users, a full-throated 
MUST seems a bit incompatible with the notion of allowing policy 
flexibility. For example, in a world where a client delivers 
revocation information out of band, as nearly every major web 
browser does today (as one example), "must staple" is of 
questionable benefit.


Browsers are the only software that use browser's implementation of 
certificate

verification and revocation.

And while they are significant users of TLS, they're definitely not the
only important users of TLS.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis - summary of the discussion

2022-01-27 Thread Viktor Dukhovni
> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer  wrote:
> 
> So our plan moving forward is to essentially keep the new text on OCSP [1] 
> and add a reference to RFC 7633 (the certificate must-staple extension). But 
> only as a MAY. In addition, we will add a MUST requirement to perform (some 
> kind of) revocation checking.

Usual lack of Internet Police noted, I feel I should mention that this "MUST" 
*will*
be ignored in various quarters.  I still have no plans to implement any 
revocation
checks in Postfix, too much pain for too little (or no) gain.

-- 
Viktor.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-25 Thread John Mattsson

> This might be overstating the case a little bit.

Yes, I agree that “not at all” is overstating things. Revocation is a very 
complex issue, most absolute statements are probably wrong. “Not a replacement 
in general” might be a better formulation. It might be a replacement in some 
use cases, but these use cases would then have quite low requirements on 
revocation.

I agree that in your example, OCSP stapling with a week-long lifetime for the 
end-certificate only and a certificate with a week-long lifetime give exactly 
the same security. But

-  Certificates with one-week lifetimes is not common and 
will maybe never be common. It also creates work for both the CA and the 
device. This is not practical for constrained IoT. CA systems in critical 
infrastructure often do not use OCSP at all due to the risk of 
denial-of-service attacks and rely purely on CRLs.

-  The OCSP stapling example you give is a quite specific 
example (Web/HTTPS). The level of revocation checking in the example is quite 
low. For many current IPsec deployments, revocation checking is done daily or 
several times per day. (D)TLS is often replacing IPsec in virtualized 
environments. One week is quite a long time and in your example revocation 
checking is only done for the end-entity certificate. Some systems check the 
revocation status of all the certificates in the chain. In cases with 
fraudulently issues certificates, they are often used immediately and a 
week-long lifetimes  (certificates or OCSP responses does not help).

-  And obviously short-term end-entity certificates do not 
protect against revoked intermediate or self-issued CA certificates.

John

From: Uta  on behalf of Daniel Kahn Gillmor 

Date: Monday, 24 January 2022 at 17:19
To: uta@ietf.org , t...@ietf.org 
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certificates, but not at all a replacement
> for revocation checking.

This might be overstating the case a little bit.  If revocation checking
is done by OCSP stapling, then the OCSP validity window *is* in effect
the duration of a "short-lived certificate".  To the extent that a
short-lived certificate has the same validity period as an OCSP
response, it is indeed a replacement for revocation checking.

As an example, the validity window of the stapled OCSP response i see
according to the cert i get on port 443 of www.ietf.org<http://www.ietf.org> 
has this
validity window:

This Update: Fri Jan 21 01:21:02 UTC 2022
Next Update: Fri Jan 28 00:36:02 UTC 2022

But when i query the OCSP responder directly i get this validity window:

This Update: Mon Jan 24 01:21:00 UTC 2022
Next Update: Mon Jan 31 00:36:00 UTC 2022

The week-long range is pretty comon, and a week-long certificate would
offer just as much protection against certificate misuse (an adversary
misusing a certificate with stapled OCSP could cache the last "good"
OCSP response and continue stapling it until it expires).

So unless "revocation checking" is defined to mean "out-of-band
confirmation with the issuing authority" (which would introduce both
latency and privacy concerns, so let's not go there), then a short-lived
certificate is indeed a replacement for revocation checking.

However, under the current certificate transparency regime, short-lived
certificates pose a challenge to CT logs, which scale with the number of
certificates issued over a given time period.  Replacing every 3-month
certificate with a corresponding number of 1-week certificates would
increase the size of CT logs by a factor of at least 12 -- probably
more, since certificates are generally issued with some overlap to
account for server-side work at cert transition and client-side clock
skew.

So, arguably, the advantage of revocation checking via OCSP stapling
over short-lived certificates today has to do with keeping CT logs a
manageable size, not with any particular security gain in terms of
revocation functionality.

--dkg

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-24 Thread Ryan Sleevi
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor 
wrote:

> So, arguably, the advantage of revocation checking via OCSP stapling
> over short-lived certificates today has to do with keeping CT logs a
> manageable size, not with any particular security gain in terms of
> revocation functionality.


Although I agree with your conclusion about equivalencies on revocation
being a function of the lifetime, an observation Dan Geer made 24 years ago
[1], a slight correction to the above remark.

This hasn't been a practical issue/concern for quite some time now,
especially with the adoption of "time-sharded" CT logs. The sharding
function of the logs can easily be adjusted to whatever target growth
function exists. That is, rather than sharding logs annually (where a log
only contains certificates expiring within a given calendrical year), it
could be sharded quarterly or semi-annually. Of course, modern logs are far
more scalable these days then original implementations, so even here, the
size of the log is more a function for monitors and auditors.

[1] https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html - Search
"Hence, a rule of thumb"
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-24 Thread Daniel Kahn Gillmor
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certificates, but not at all a replacement
> for revocation checking.

This might be overstating the case a little bit.  If revocation checking
is done by OCSP stapling, then the OCSP validity window *is* in effect
the duration of a "short-lived certificate".  To the extent that a
short-lived certificate has the same validity period as an OCSP
response, it is indeed a replacement for revocation checking.

As an example, the validity window of the stapled OCSP response i see
according to the cert i get on port 443 of www.ietf.org has this
validity window:

This Update: Fri Jan 21 01:21:02 UTC 2022
Next Update: Fri Jan 28 00:36:02 UTC 2022

But when i query the OCSP responder directly i get this validity window:

This Update: Mon Jan 24 01:21:00 UTC 2022
Next Update: Mon Jan 31 00:36:00 UTC 2022

The week-long range is pretty comon, and a week-long certificate would
offer just as much protection against certificate misuse (an adversary
misusing a certificate with stapled OCSP could cache the last "good"
OCSP response and continue stapling it until it expires).

So unless "revocation checking" is defined to mean "out-of-band
confirmation with the issuing authority" (which would introduce both
latency and privacy concerns, so let's not go there), then a short-lived
certificate is indeed a replacement for revocation checking.

However, under the current certificate transparency regime, short-lived
certificates pose a challenge to CT logs, which scale with the number of
certificates issued over a given time period.  Replacing every 3-month
certificate with a corresponding number of 1-week certificates would
increase the size of CT logs by a factor of at least 12 -- probably
more, since certificates are generally issued with some overlap to
account for server-side work at cert transition and client-side clock
skew.

So, arguably, the advantage of revocation checking via OCSP stapling
over short-lived certificates today has to do with keeping CT logs a
manageable size, not with any particular security gain in terms of
revocation functionality.

--dkg


signature.asc
Description: PGP signature
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Daniel Kahn Gillmor
On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote:
>> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor  
>> wrote:
>
>> Do you think that DNSSEC should be soft-fail for CAA checks, or should
>> we urge the CAs to be more strict here?  Perhaps that would be another
>> recommendation.
>
> CAA lookups must not softfail.  This needs to be the case whether the
> domain is signed or not.  For signed domains this means that validation
> of the response (positive or denial of existence) must succeed.  Bogus
> replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
> be hard errors (for signed and unsigned domains alike).

fwiw, Let's Encrypt's ACME-compliant CA implementation "boulder"
apparently does not softfail for CAA validation:

   https://github.com/letsencrypt/boulder/issues/5903#issuecomment-1018932892

So there's at least one piece of good news in this thread.

   --dkg


signature.asc
Description: PGP signature
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Eric Rescorla
This discussion seems kind of out of scope for 7525-bis, which is about how
to use TLS, but doesn't seem to say much of anything in terms of how to
operate a CA.

The current draft seems not to say anything about what clients ought to do
and to say that servers SHOULD support OCSP and OCSP stapling (though the
citation to 6961 is weird because it seems to be referred to twice). My
sense is that it probably ought to say:

- Clients should have some mechanism for dealing with revocation, at least
in high value cases
  - For the reasons rsleevi indicates it may be desirable that it not be
totally unfiltered
  - None of the standardized mechanisms are acceptable here, OCSP for
privacy and performance reasons, and stapling for deployment reasons

- Servers SHOULD (MAY?) support stapling for clients which don't have
another mechanism, but shouldn't expect a lot of use.

This last seems a bit 6919ish, tbh.

-Ekr


On Fri, Jan 21, 2022 at 10:31 AM Ryan Sleevi 
wrote:

>
>
> On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni 
> wrote:
>
>> > Do you think that DNSSEC should be soft-fail for CAA checks, or should
>> > we urge the CAs to be more strict here?  Perhaps that would be another
>> > recommendation.
>>
>> CAA lookups must not softfail.  This needs to be the case whether the
>> domain is signed or not.  For signed domains this means that validation
>> of the response (positive or denial of existence) must succeed.  Bogus
>> replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
>> be hard errors (for signed and unsigned domains alike).
>>
>
> Yes, and OCSP lookups must not softfail either, in order for them to be
> useful.
>
> Unfortunately, the real world is messy and complex, and the incentives for
> getting to such a system for CAA are, unfortunately, greatly misaligned -
> for CAs, but also for server operators and all the intermediaries along the
> line.
> ___
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Viktor Dukhovni
On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote:

> > > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > > we urge the CAs to be more strict here?  Perhaps that would be another
> > > recommendation.
> >
> > CAA lookups must not softfail.  This needs to be the case whether the
> > domain is signed or not.  For signed domains this means that validation
> > of the response (positive or denial of existence) must succeed.  Bogus
> > replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
> > be hard errors (for signed and unsigned domains alike).
> 
> Yes, and OCSP lookups must not softfail either, in order for them to be
> useful.

>From where I sit, issuance is a much more critical process than
revocation, and sloppy practices should not be acceptable.  Postfix does
not ignore DNS lookup errors, and the sky has not fallen.  I don't see
why a CA should be at liberty to do so.

If some domain has broken DNS preventing certificate issuance, then they
need to fix that first.  Both the nameservers and the CA can be expected
to be on a better than hotel captive portal network, where DNS is
sufficiently reliable to return a valid answer, or be attended to if
there's a problem.

If CA/B Forum CAs are ignoring CAA lookup errors then the WebPKI is even
weaker than I thought it was.

-- 
Viktor.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Ryan Sleevi
On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni 
wrote:

> > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > we urge the CAs to be more strict here?  Perhaps that would be another
> > recommendation.
>
> CAA lookups must not softfail.  This needs to be the case whether the
> domain is signed or not.  For signed domains this means that validation
> of the response (positive or denial of existence) must succeed.  Bogus
> replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
> be hard errors (for signed and unsigned domains alike).
>

Yes, and OCSP lookups must not softfail either, in order for them to be
useful.

Unfortunately, the real world is messy and complex, and the incentives for
getting to such a system for CAA are, unfortunately, greatly misaligned -
for CAs, but also for server operators and all the intermediaries along the
line.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Viktor Dukhovni
> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor  
> wrote:
> 
>> Without wanting to detract too much from the core question of the thread,
>> how does this address the routing gap? The adversary at the routing layer
>> just redirects the host being validated to control the key that way, and
>> simply interrupts the nameserver during the CAA check. In the threat model
>> you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA
>> checks.
> 
> If DNSSEC is soft-fail for the CA verifying CAA checks, then i agree
> this is insufficient.  The letsencrypt implementation is apparently at
> least logging the info about DNSSEC signatures.
> 
>   https://github.com/letsencrypt/boulder/issues/2700
> 
> Do you think that DNSSEC should be soft-fail for CAA checks, or should
> we urge the CAs to be more strict here?  Perhaps that would be another
> recommendation.

CAA lookups must not softfail.  This needs to be the case whether the
domain is signed or not.  For signed domains this means that validation
of the response (positive or denial of existence) must succeed.  Bogus
replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
be hard errors (for signed and unsigned domains alike).

-- 
Viktor.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Daniel Kahn Gillmor
On Fri 2022-01-21 15:23:56 +, Salz, Rich wrote:
> Second, there is the history of poor behavior by some CA's, which
> leads to the primary user agent (browsers, or perhaps TLS runtimes)
> not being able to just completely trust them. Perhaps that historic
> era has passed, and it is time for user agents to end their probation
> of CA's? Not for me to say.

The argument of "we don't trust (some of) the CAs" is usually used to
mean "we are not willing to accept their cryptographic assertions of
identity in certain contexts".

But here, you're using it to mean "we are going to accept their
cryptographic assertions of identity even in contexts that they claim
are not valid".

This is a surprising inversion.

 --dkg


signature.asc
Description: PGP signature
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-21 Thread Salz, Rich
>I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.

For that, you mainly want certificate transparency, no?

>   If certificate validation is the process of confirming what a CA says,
then a CA that has said "this certificate should not be considered valid
unless you also have a reasonable proof of freshness" is pretty
unequivocal.

While I like this sentiment, I think there are a couple of arguments against 
it. First, there's the ever-present escape hatch of out of band, or local 
policy. Second, there is the history of poor behavior by some CA's, which leads 
to the primary user agent (browsers, or perhaps TLS runtimes) not being able to 
just completely trust them. Perhaps that historic era has passed, and it is 
time for user agents to end their probation of CA's? Not for me to say.

> But once you're ignoring what the CA actually wrote
and signed in the certificate, you're on your own.

It's not that I'm on my own, but that the user agent is deciding.  Now, I grant 
that the vast majority of users are not capable of making a decision, let alone 
an informed one, but I think it might be useful for us to keep phrasing things 
in terms of user agent.

> The choice about whether to require stapling or not _is_ a policy
> decision relevant not only to server operators, but also relying
> parties, and can be easily abused by CAs if given that lever.

What kind of abuse are you anticipating here?  can you spell it out in
more detail?

+1  I suppose they could DoS their own customers, or upcharge them or something.

And +1 to getting answers to the rest of DKG's questions.  In theory, this note 
shouldn't need any reply :)

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-19 Thread Nick Sullivan
For additional context, here's s research study we published a few years
back on OCSP must-staple in the Web context:
https://cbw.sh/static/pdf/chung-imc18.pdf

Nick

On Wed, Jan 19, 2022 at 11:58 AM Mohit Sahni  wrote:

> Hi,
> > So for the new BCP, we have three options:
> >
> > Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly
> also TLS 1.2 implementations) to fail the handshake if the OCSP response is
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
> > Remove the whole discussion of OCSP, saying that in its current form
> it’s not adding value.
> > Maintain the status quo, where many people implement OCSP on the server
> side, but clients rarely benefit.
> >
> I don't think that OCSP is not adding value in its current form. I
> have seen a lot of OCSP implementations with hard fail, especially on
> the server side for authenticating clients using private PKI
> certificates. Although OCSP does not add much value on the client side
> as it's a bit fragile for public PKI and client side checks because of
> the matrix of multiple OCSP status producers and consumers at scale.
>
> -Mohit
>
> ___
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


Re: [Uta] [TLS] OCSP in RFC7525bis

2022-01-19 Thread Mohit Sahni
Hi,
> So for the new BCP, we have three options:
>
> Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also 
> TLS 1.2 implementations) to fail the handshake if the OCSP response is 
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
> Remove the whole discussion of OCSP, saying that in its current form it’s not 
> adding value.
> Maintain the status quo, where many people implement OCSP on the server side, 
> but clients rarely benefit.
>
I don't think that OCSP is not adding value in its current form. I
have seen a lot of OCSP implementations with hard fail, especially on
the server side for authenticating clients using private PKI
certificates. Although OCSP does not add much value on the client side
as it's a bit fragile for public PKI and client side checks because of
the matrix of multiple OCSP status producers and consumers at scale.

-Mohit

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta