> On Jul 28, 2021, at 12:41, Sean Turner wrote:
>
> Daniel,
>
> Thanks for following up on this (I meant to and dropped the ball). Triminng
> to the remaining issue.
>
> spt
>
>>
>>> 6. Updates to RFC5246
>>>
>>> [RFC5246], The Transport Layer Security (TLS) Protocol Versio
Daniel,
Thanks for following up on this (I meant to and dropped the ball). Triminng to
the remaining issue.
spt
>
> >> >> > 6. Updates to RFC5246
> >> >> >
> >> >> > [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
> >> >> > suggests that implementations can assume sup
Hi,
Thanks Logan for posting the new version. I am trying to summarize where we
are with version 07. I think there is one remaining concern that has not
been addressed, though it is not clear to me how we agreed to address it.
Yours,
Daniel
On Tue, May 4, 2021 at 11:17 PM Daniel Migault wrote:
Hi,
Thanks for the update and the followup. To me the only remaining point I am
not sure has been fully addressed is the clarification of 5246, but
otherwise we agree on the content to be written. Please find my comments
inline.
Yours,
Daniel
On Tue, May 4, 2021 at 1:23 PM Sean Turner wrote:
>
Daniel,
Thanks for your (and the WG’s) patience on this. Responses in line.
spt
> On Apr 9, 2021, at 14:54, Sean Turner wrote:
>> On Jan 22, 2021, at 08:23, Daniel Migault wrote:
>> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron
>> wrote:
>> On Fri, Jan 22, 2021 at 7:30 AM Daniel Miga
> On Jan 21, 2021, at 16:50, Daniel Migault wrote:
>
> Hi,
>
> First I deeply apologize for taking so long to respond, I just realized now
> these responses.
No worries it does happen that I miss email from time to time too ;)
> I do not believe a review of IoT protocol is needed, I am mo
On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron
wrote:
> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault
> wrote:
> >
> > Hi,
> >
> > I apology for responding so late - I missed the thread. I want this
> document to be moved forward but so far I do not have the impression my
> concerns have
On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault wrote:
>
> Hi,
>
> I apology for responding so late - I missed the thread. I want this document
> to be moved forward but so far I do not have the impression my concerns have
> been addressed. I suppose that results from my lake of responsiveness an
Hi,
I apology for responding so late - I missed the thread. I want this
document to be moved forward but so far I do not have the impression my
concerns have been addressed. I suppose that results from my lake of
responsiveness and I apology. Please find my response inline and let me
know what can
Hi,
First I deeply apologize for taking so long to respond, I just realized now
these responses.
I do not believe a review of IoT protocol is needed, I am more thinking
that TLS document should serve as a base guidance for TLS. Specific needs
for IoT are addressed based on the generic guidances.
Daniel,
Alessandro created a PR to resolve your comments as suggested by me:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12
I was unable to propose text for all of your comments. Please review this email
as well as the PR as well so we can move this I-D along.
Cheers,
spt
>
> 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
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
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
14 matches
Mail list logo
