[Uta] Hammurabi: A Framework for Pluggable, Logic-Based X.509 Certificate Validation Policies

Hey folks-- I thought that people in UTA might be interested in this recent academic work on teasing apart various facets of X.509 validation: https://cbw.sh/static/pdf/larisch-ccs22.pdf This is: "Hammurabi: A Framework for Pluggable, Logic-Based X.509 Certificate Validation Policies"

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

Re: [Uta] [TLS] OCSP in RFC7525bis

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

Re: [Uta] [TLS] OCSP in RFC7525bis

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

Re: [Uta] OCSP in RFC7525bis

On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote: > * 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.) This sounds a

Re: [Uta] More TLS bits to record?

On Tue 2019-01-15 18:21:48 -0500, Viktor Dukhovni wrote: > On Jan 15, 2019, at 5:21 PM, Stephen Farrell > wrote: > >> Well, not until you get to ESNI and fingerprinting different >> handshake instances as a way to track a message down a chain >> of MTAs. > > This is mail, not HTTP. If you get

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

On Tue 2019-01-15 01:50:33 -0500, Viktor Dukhovni wrote: > where the "TCP-Info" in the "BY" clause records the SNI name? Is that > right? It is an interesting idea, but perhaps that boat had sailed > many decades ago? Starting with Sendmail versions going back to at > least the mid 1980's, the

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

On Mon 2019-01-14 18:09:41 -0500, John R Levine wrote: > On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote: >> On Mon 2019-01-14 16:43:15 -0500, John Levine wrote: >>> To show that you read it, please include the first word in the text >>> on page 50 of RFC 5321 in

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

On Mon 2019-01-14 22:29:50 -0500, John Levine wrote: > When the ABNF about extended-domain was written with the comment about > info derived from the TCP connection, the TCP connection was > synonymous with the transport. Now the transport is TCP plus STARTTLS > in various versions plus SNI, none

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

On Mon 2019-01-14 16:43:15 -0500, John Levine wrote: > To show that you read it, please include the first word in the text > on page 50 or RFC 5321 in your reply. I'm sorry to spoil it for everyone that the word is "The" :P John, i think you're talking about (ab)using the Domain variant of the

[Uta] storing SNI in the Received header [was: Re: how to log, was flake ho, was MTA-STS with lots of domains]

On Mon 2019-01-14 14:48:58 -0500, John Levine wrote: > Today's question: I would like to log the SNI in the Received header. > Where should I put it? > > One possibilty would be to use the SNI name as the by-domain in the BY > clause, but that makes it hard to tell that the name came from SNI >

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

On Mon 2019-01-07 06:42:10 -0800, Alice Wonder wrote: > If it were up to me, an RFC would be published deprecating opportunistic > TLS for SMTP. > > System administrators would have three years, but after that, TLS 1.3+ > would be required for SMTP. There is precedent for far-reaching flag days

Re: [Uta] SNI text from 7672

On Thu 2018-03-22 14:49:18 -0400, Viktor Dukhovni wrote: > https://tools.ietf.org/html/rfc7672#section-8.1 > > >[...] The >server MAY rely on SNI to determine which certificate chain to >present to the client. Clients that don't send SNI information may >not see the expected

Re: [Uta] RequireTLS: NO

On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote: >> On Mar 22, 2018, at 2:59 PM, Martin Thomson wrote: >> >> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is >> relevant. > > A reasonable guiding principle, but sometimes *availability*

Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

On Fri 2015-02-20 16:08:17 -0500, Peter Saint-Andre - yet wrote: Since we seem to all be on the same page, I'm going to submit -11 with this text and Viktor's little modp fix so that we can all move on with our lives... If we could use the term finite field instead of modp, that would align

[Uta] DEEP: permanent latching for TLS and domain name reputation

I was asked to echo my comments to the list about timeouts for TLS latching in the discussion about DEEP. One of the main reasons that people seem to want timeouts for TLS latching is because they're worried about bricking their domain, or about setting policies that will affect the domain after

Re: [Uta] UTA discussion of fallback dance? [was: Re: reminder: call for agenda items]

On Thu 2014-11-06 11:27:14 -0800, Leif Johansson wrote: On 2014-11-06 19:47, Daniel Kahn Gillmor wrote: On 11/06/2014 01:35 PM, Leif Johansson wrote: You volunteering to talk about [the TLS fallback dance] at UTA? I don't have any draft written, but i am certainly willing to float the topic