This works for me, does anyone object to my updating the PR in this fashion?
-Ekr
On Thu, May 18, 2017 at 2:10 AM, Brian Smith wrote:
> Kathleen Moriarty wrote:
> > 4. Section 6.2 Error Alerts
> >
> > In addition to sending the error, I don't see any mention of the error
> > being logged on t
On 18 May 2017 at 09:08, Eric Rescorla wrote:
> This works for me, does anyone object to my updating the PR in this fashion?
Go ahead.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Dan,
Thank you for your reviews and comments. I believe the following text provides
more explanation on how the provided cipher suites are negotiated by TLS1.3 as
well as why point codes defined in the document does not apply to TLS1.3. Feel
free to let me know if that address your concern
Hi Simon,
Thank you for the review. I believe we have addressed your comments in our
version 04. Please see my comments inline.
Yours,
Daniel
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Simon Friedberger
Sent: Thursday, May 04, 2017 5:59 PM
To: i...@ietf.o
Hi Daniel,
Thank you for your response, and for addressing my comment. Yes, the edits
address my concern, this is exactly the kind of clarification text that IMO
was missing. I suggest to publish the revised version as soon as you
address all other comments. The document can be approved by the IES
One small nit.
> ECDHE provides perfect forward secrecy
I thought we had decided to change “perfect forward secrecy” to just “forward
secrecy” since “perfect” is such a difficult standard to reach?
Tim
—
Tim Jackson | Product Security Architect | MobileIron, Inc.
On 5/18/17, 10:45 AM, "TLS on b
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : Exported Authenticators in TLS
Author : Nick Sullivan
Filename: draft-ietf-tls-exported
It is a mathematical cryptographic term, and as such is incontrovertible.
I say leave it in.
Regards,
Uri
Sent from my iPhone
> On May 18, 2017, at 16:58, Timothy Jackson wrote:
>
> One small nit.
>
>> ECDHE provides perfect forward secrecy
> I thought we had decided to change “perfect forw
Hi,
Thanks Tim and Uri for the comment. At least wikipedia considers them as
equivalent. I am fine either way, but leave it as pfs unless there is a
consensus to change it to forward secrecy. If having fs seems important to
you please let us know asap!
Yours,
Daniel
On Thu, May 18, 2017 at 5:01
Instead of our in addition to the Wiki, check scholarly references. E.g.,
Introduction to Modern Cryptography, Handbook of Applied Cryptography, etc.
Regards,
Uri
Sent from my iPhone
> On May 18, 2017, at 17:18, Daniel Migault wrote:
>
> Hi,
>
> Thanks Tim and Uri for the comment. At least
I don't much care, but we've moved to "forward secrecy" in TLS 1.3.
-Ekr
On Thu, May 18, 2017 at 5:17 PM, Daniel Migault wrote:
> Hi,
>
> Thanks Tim and Uri for the comment. At least wikipedia considers them as
> equivalent. I am fine either way, but leave it as pfs unless there is a
> consen
> On May 18, 2017, at 5:30 PM, Eric Rescorla wrote:
>
> I don't much care, but we've moved to "forward secrecy" in TLS 1.3.
That's increasingly the more appropriate term. Yes, historically
the word "perfect" was there too, but these days we understand that
it is only as perfect as the ephemera
All,
During the WG call for adoption, a couple of questions were raised about
comparison/analysis of sub-certs versus proxy and/or short-lived certificates.
There is some discussion currently in the draft, but the chairs feel that these
issues need further discussion (and elaboration in the dr
Hi all,
I have reviewed this document as part of the security 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 editors and WG chairs should
treat these comments ju
14 matches
Mail list logo
