On Fri, 27 Nov 2020 23:43:42 -0500
Keith Moore wrote:
> I'm aware of that. But what really is the point of a cert
> (especially one issued by a public CA) that has an RFC1918 address as
> its subject? Not that it matters that much because the vast majority
> of sites using embedded systems aren'
Hi Nancy
On Mon, 26 Oct 2020 02:55:52 +
"Nancy Cam-Winget (ncamwing)" wrote:
> [NCW] The specific conditions are more deployment and vendor specific
> and proprietary so it'd be difficult to enumerate (and enumerate them
> all)...as well as which we believe is out of scope for the document.
On Fri, 02 Oct 2020 14:15:48 -0400
"Michael D'Errico" wrote:
> > > You can't possibly implement [stateless HelloRetryRequest] the
> > > way the spec suggests with just a hash in a HRR cookie extension.
Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here m
On Wed, 23 Sep 2020 05:51:24 -0700
Eric Rescorla wrote:
> I think this misunderstands the point.
>
> Suppose I want to add feature X. There are (at least) two scenarios:
>
> 1. Add a new feature and it just works.
> 2. I have to get it added to the YANG module, then get middlebox
> vendors to c
On Fri, 11 Sep 2020 12:32:03 +0530
tirumal reddy wrote:
> The MUD URL is encrypted and shared only with the authorized
> components in the network. An attacker cannot read the MUD URL and
> identify the IoT device. Otherwise, it provides the attacker with
> guidance on what vulnerabilities may b
On Thu, 20 Aug 2020 09:58:58 -0400
Roelof DuToit wrote:
> As co-author I am not a proponent of passive TLS inspection - not
> least because of the ossification implications. It cannot be labeled
> as ineffective though (see further comments below), even if the
> document strongly hints at not us
On Wed, 19 Aug 2020 18:45:44 +
Nancy Cam-Winget (ncamwing)" wrote:
> Section 4.2 Encrypted Server Certificate describes a practice
> which is inherently unsound. Passive inspection of the Certificate
> message from TLS 1.2 or earlier isn't a reliable source of
> information because a pas
I am not very familiar with IETF working group practices, however it
strikes me as surely unusual to have a document enter Last Call
(supposedly believed by its owners to be ready for publication) and yet
immediately then be revised showing it was in fact not ready at all.
However this seems to be
Hi,
My impression from watching Tuesday's session is that this probably
can't end up as a Working Group document, but nevertheless people
seem to keep looking at it and so it's worth fixing errors.
Eric Rescorla touched on this I think briefly, but I want to be more
forthright:
Section 2.2.1 of
In section 7.1 the -02 draft says:
Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but DoH/DPRIVE are also defenses against
DNS attacks by attackers on the local network, which is a common case
where SNI.
Where SNI what?
I'd be tempt
10 matches
Mail list logo
