On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
> >> """The expectation is that TLSv1.2 will continue to be used for
> >> many years alongside TLSv1.3."""
>
> So is your proposed change to only remove that sentence?
I just checked, and it seems like the only thing the document says along t
On Thu, Sep 26, 2019 at 8:03 PM Martin Thomson wrote:
> So I agree with Kathleen's conclusion: not to change the goals of the
> current document. But there are changes that I think are necessary (and
> thanks to Daniel and John for highlighting these).
>
> BTW, I've moved this to the TLS working
Hiya,
On 27/09/2019 01:02, Martin Thomson wrote:
> So I agree with Kathleen's conclusion:
Me too, FWIW.
> not to change the goals of the
> current document. But there are changes that I think are necessary
> (and thanks to Daniel and John for highlighting these).
>
> BTW, I've moved this to
So I agree with Kathleen's conclusion: not to change the goals of the current
document. But there are changes that I think are necessary (and thanks to
Daniel and John for highlighting these).
BTW, I've moved this to the TLS working group, because this is an active topic
there and I don't see
On 9/26/2019 11:38 AM, Roman Danyliw wrote:
> Hi Christian!
>
> Thanks for all of the updates. I have a remaining items are described inline.
>
> To bring up a new item, there was new text introduced in -06 of Section 5 to
> which I strongly object. Specifically:
>
> "Replacing clear text SNI t
Hi Christian!
Thanks for all of the updates. I have a remaining items are described inline.
To bring up a new item, there was new text introduced in -06 of Section 5 to
which I strongly object. Specifically:
"Replacing clear text SNI transmission by an encrypted variant will
also thwart
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: Wednesday, September 25, 2019 8:42 PM
> To: Roman Danyliw
> Cc: Christian Huitema ; The IESG ;
> draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Roman Danyliw's No Ob
Hi,
My understanding of deprecating of TLS1.0 TLS 1.1 is that:
a) new software do not use these versions
b) existing software stop supporting these versions.
I am not sure how likely a new software is to use TLS 1.0 or TLS 1.1 with
TLS 1.2 and TLS 1.3 being widely deployed. It seems also a curren
Thanks for raising this discussion John, we have been struggling with this
in curdle as well and ipsecme. This is also a topic that I believe would be
useful to improve the security.
One aspect is that some implementers go to the IANA pages and believe that
everything on the pages is acceptable. I
First, I think that we must recognize that the *IETF* does not have the same
sectoral powers that 3GPP has. It is entirely appropriate what 3GPP
did, and they seem to have learned the lessons they needed.
John Mattsson wrote:
> How can IETF be more pro-active regarding depreca
Sent from my mobile device
> On Sep 26, 2019, at 9:02 AM, Salz, Rich wrote:
>
> These are excellent points. Perhaps they can be squeezed into
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ ?
> It's been waiting 90 days, a brief reset might not hurt :)
>
This wou
These are excellent points. Perhaps they can be squeezed into
https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ ? It's
been waiting 90 days, a brief reset might not hurt :)
On 9/26/19, 8:18 AM, "John Mattsson"
wrote:
Hi,
Hopefully, we have learned some le
Hi,
Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1
deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a
myriad subtle ways and should according to me optimally have been deprecated
years ago.
3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could
13 matches
Mail list logo
