Reviewer: Meral Shirazipour
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please treat these comments just like any other last call comments.
For
Reviewer: Daniel Migault
Review result: Ready with Nits
Hi,
I reviewed this document as part of the IoT Directorate's ongoing effort to
review all IETF documents being processed by the IESG. These comments were
written primarily for the benefit of the Security Area Directors. Document
authors,
To address the comment below, keeping weak security is likely to weaken
current and future IoT communications, so I do not think there is room for
compromise with performance. Of course this is in a context of TLS. I
expect protocol to leverage from TLS security, so the impact should be
rather neg
Hi,
I would like to test an ECH-enabled client, but am struggling to find a
public test server with a published ECHconfig in its HTTPS record.
Do any yet exist?
I've looked in all these places, but none are mentioned:
https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementation-Status
https:
Hiya,
The latest ECH draft from Oct 16 says "ECH uses draft-05 of
HPKE for public key encryption."
The latest HPKE draft (-06) from Oct 23 has a few minor
incompatible changes (for good but relatively trivial
reasons).
So for interop ECH apparently requires use of an outdated
I-D, despite the
On 27/10/2020 18:37, Chris Box (BT) wrote:
Hi,
I would like to test an ECH-enabled client, but am struggling to find a
public test server with a published ECHconfig in its HTTPS record.
Do any yet exist?
I've looked in all these places, but none are mentioned:
https://github.com/tlswg/draft-
Stephen,
I don't think what you're complaining about can be attributed to GitHub. Tools
are just tools, how they're used is what's relevant (i.e., this could just as
easily happen over e-mail).
Cheers,
> On 28 Oct 2020, at 7:31 am, Stephen Farrell wrote:
>
>
> Hiya,
>
> The latest ECH dra
Hiya,
On 27/10/2020 22:28, Mark Nottingham wrote:
Stephen,
I don't think what you're complaining about can be attributed to
GitHub. Tools are just tools, how they're used is what's relevant
(i.e., this could just as easily happen over e-mail).
Sorta. I doubt the volume of traffic would've ha
On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 27/10/2020 22:28, Mark Nottingham wrote:
> > Stephen,
> >
> > I don't think what you're complaining about can be attributed to
> > GitHub. Tools are just tools, how they're used is what's relevant
> > (i.e., this could just a
Hiya,
On 27/10/2020 23:06, Eric Rescorla wrote:
On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
wrote:
Hiya,
On 27/10/2020 22:28, Mark Nottingham wrote:
Stephen,
I don't think what you're complaining about can be attributed to
GitHub. Tools are just tools, how they're used is what's
re
On Tue, Oct 27, 2020 at 4:20 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 27/10/2020 23:06, Eric Rescorla wrote:
> > On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 27/10/2020 22:28, Mark Nottingham wrote:
> >>> Stephen,
> >>>
> >>> I don't think what yo
>I don't think what you're complaining about can be attributed to GitHub.
> Tools are just tools, how they're used is what's relevant (i.e., this could
> just as easily happen over e-mail).
Frictionless and increased speed can be its own drawback.
___
On 27/10/2020 23:27, Eric Rescorla wrote:
In fact, it*is* the IETF process, or rather one permitted IETF process,
since RFC 8874.
I don't believe the current case matches my recollection of
that, but I've not checked in detail. The lack of list
discussion certainly smells wrong to me.
If
<#secure method=pgpmime mode=sign>
Daniel Migault via Datatracker wrote:
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2].
> Reading the text the situation of HMAC with
> MD5 is unclear. Si
Stephen,
Given that there appears to be emerging consensus around the "issue discussion
mode with email summaries sounds" presented in Chris' email from just last week
can we let that settle?
We can certainly get a summary together - granted there have been interim
meetings with published minu
> On Oct 27, 2020, at 19:44, Michael Richardson wrote:
>
>
> <#secure method=pgpmime mode=sign>
>
> Daniel Migault via Datatracker wrote:
>> RFC6194 may be mentioned as a reference for
>> not deprecating HMAC-SHA-1 as well as an
>> additional reference to [NISTSP800-131A-R2].
>
>> Reading
Hiya,
On 28/10/2020 00:32, Sean Turner wrote:
Stephen,
Given that there appears to be emerging consensus around the "issue
discussion mode with email summaries sounds" presented in Chris'
email from just last week can we let that settle?
My bet is that yes the WG will land on that bad answer
Please note the comment about Section 3 suggests changing server behavior from
SHOULD NOT to a MUST NOT.
> On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker
> wrote:
>
> Reviewer: Daniel Migault
> Review result: Ready with Nits
>
> Hi,
>
>
> I reviewed this document as part of the
> On Oct 27, 2020, at 10:32, Daniel Migault wrote:
>
> To address the comment below, keeping weak security is likely to weaken
> current and future IoT communications, so I do not think there is room for
> compromise with performance. Of course this is in a context of TLS. I expect
> protoc
19 matches
Mail list logo
