On 4/20/21 7:00 PM, Martin Thomson wrote:
> On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
>> Taking a step back, it would be great if we could reach consensus on
>> whether or not this is a use case we actually want to solve.
>
> The Web currently recognizes IP certificates. The specs
>All that said, IP certificates are naturally a feature with narrow
> applicability. For something like ECH fallback, which should be rare, we
> benefit more from reduced options and simplicity than we do by enabling niche
> features. Adding a dependency on a rarely used feature, optional
> That in turn implies that getting an IP-based certificate might be easier
> than a DV certificate (and the associated name). I'd need more supporting
> evidence to believe that. Under what conditions could that be true?
I'm not making any claims at all about the ease with which one can get
On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote:
> > I'm not sure what you are implying might be impossible. Are you suggesting
> > that it might be impossible to get a name for which you could get a
> > certificate?
>
> No. I'm implying that if we don't allow clients to authenticate
> cl
> In general, I'd prefer we get ECH deployed for some major use
> cases and not try fill in every possible niche at this point.
That's fine with me.
> On Apr 20, 2021, at 7:03 PM, Stephen Farrell
> wrote:
>
>
> Hiya,
>
> To answer Chris' initial question: I can't currently think of
> a real
Hiya,
To answer Chris' initial question: I can't currently think of
a real use-case where the client would need to authenticate
an IP address for a client-facing server in the event that
ECH decryption has been tried and failed.
And, I very much sympathise with Martin's goal of simplifying
if w
> I'm not sure what you are implying might be impossible. Are you suggesting
> that it might be impossible to get a name for which you could get a
> certificate?
No. I'm implying that if we don't allow clients to authenticate client-facing
servers with an IP-based certificate, ECH won't be pos
On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote:
> This does sound unusual. That said, if this sort of set-up is possible
> (which presumably it is), it seems unfortunate to make ECH impossible
> in that scenario.
I'm not sure what you are implying might be impossible. Are you suggesting
> we're talking about a host that fronts for multiple different names, so I'm
> finding it hard to imagine how finding a name usable for this purpose would
> be challenging.
This does sound unusual. That said, if this sort of set-up is possible (which
presumably it is), it seems unfortunate to
On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
> Taking a step back, it would be great if we could reach consensus on
> whether or not this is a use case we actually want to solve.
The Web currently recognizes IP certificates. The specs, thanks RFC 6125,
largely missed this, but we're
Issue #424 tracks whether or not we want to allow clients to authenticate
client-facing servers with an IP-based certificate:
https://github.com/tlswg/draft-ietf-tls-esni/issues/424
There are a number of different proposals for _how_ we might enable this,
varying in how the name and addresse
11 matches
Mail list logo
