Hi Francesca,
~ snip ~
5. -
Section 10.2
FP: Just checking - why is 53 "incompatible with this document"?
[Hannes] Maybe someone responded already regarding this point. I don't know
whether it is good or bad practice to provide all this background in the IANA
considerations but the story
Hi John, Hi Ekr,
Regarding the presentation language used in the document I have added a
clarification to the terminology section, see
https://github.com/tlswg/dtls-conn-id/pull/110.
I hope this addresses the issue.
Ciao
Hannes
From: Eric Rescorla
Sent: Tuesday, April 20, 2021 11:32 PM
To:
Hi John, Hi Ekr,
I hope I correctly understand the essence of your conversation. I am wondering
whether a link from the bullet list to the text two paragraphs down will help.
Here is my proposal:
https://github.com/tlswg/dtls-conn-id/pull/111
Ciao
Hannes
From: John Scudder
Sent: Wednesday, Ap
HI John,
Am 21.04.21 um 00:42 schrieb John Scudder:
3. Section 6:
* There is a strategy for ensuring that the new peer address
is able
to receive and process DTLS records. No such strategy is
defined
in this specification.
This is a little mind-bog
> 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
On Apr 20, 2021, at 7:24 PM, Eric Rescorla wrote:
On Tue, Apr 20, 2021 at 3:42 PM John Scudder
mailto:j...@juniper.net>> wrote:
On Apr 20, 2021, at 5:32 PM, Eric Rescorla
mailto:e...@rtfm.com>> wrote:
3. Section 6:
* There is a strategy for ensuring that the new peer address is able
> On Apr 20, 2021, at 7:33 PM, Rob Sayre wrote:
>
> The ECH (nee ESNI) spec says "All TLS notation comes from [RFC8446], Section
> 3." Something like that should work fine here, in "Conventions and
> Terminology".
Yes, that would be fine from my point of view.
—John
_
On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote:
> On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote:
>
> This seems like a pretty basic assumption. These aren't just notational
> conventions
> or pseudo-code. They're the protocol description language that TLS is
> defined in.
> If one isn't f
On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote:
> On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote:
>
> 3. Section 6:
>>
>>* There is a strategy for ensuring that the new peer address is able
>> to receive and process DTLS records. No such strategy is defined
>> in this spe
On Apr 20, 2021, at 5:32 PM, Eric Rescorla
mailto:e...@rtfm.com>> wrote:
This seems like a pretty basic assumption. These aren't just notational
conventions
or pseudo-code. They're the protocol description language that TLS is defined
in.
If one isn't familiar with how to read this syntax, then
On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-tls-dtls-connection-id-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses incl
John Scudder has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection
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 ref
Martin Duke has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection
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 refe
Hi Francesca, thank you for your review.
The ticket to track your review is:
https://github.com/tlswg/dtls-conn-id/issues/106
cheers!
On Tue, Apr 20, 2021 at 5:22 PM Francesca Palombini via Datatracker
wrote:
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-tls
Hello Francesca,
> 5. -
>
> Section 10.2
>
> FP: Just checking - why is 53 "incompatible with this document"?
The 53 was is used with the MAC definition of the previous version 06 of
this draft. Though the MAC has been adapted, using a different extension
number makes it easier to migrate ex
Francesca Palombini has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection
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.)
Ple
24 matches
Mail list logo
