n-shared IPs. One might imagine
that some special purpose clients would choose to do so, but that's not the
case I'm talking about.
-Ekr
> On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 8:49 AM A A wrote:
>>
>
On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
I don't think there is any particul
On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie wrote:
> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few c
On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
>
>
> I don't think there is any par
On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena wrote:
>
> On 3/14/24 00:45, Eric Rescorla wrote:
> > There are two questions here:
> >
> > 1. What the specification says
> > 2. What implementations choose to do within the envelope of that
> > specification
g to skate where the puck is going.
>>>
>>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>>> agreement in the next ~6-9 years is a strong vote of confidence in any
>>> protocol doing this at all, so, TLS wouldn't be out on a limb to suppor
On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
wrote:
>
> Hiya,
>
> I think the outcome here is maybe most likely to do nothing but
> since the WGLC is ongoing I figured it best to bring it up in
> case others have better ideas.
>
Yes, I think the answer is "do nothing". TLS assumes that TCP co
On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich wrote:
> ➢ Given that we're almost there, and that only really browsers are
> asking for these hacks, and that even some of those were almost ready
> to ship without these hacks, I don't think that this is entirely
> unrealistic as an aspirat
On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote:
> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote:
> > FWIW: In my experience middleboxes don't ossify based on what the spec
> says,
> > they ossify based on what they see on the wire. So, if common
> > implementations send CCS in a particul
On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos
wrote:
> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote:
> >
> >
> > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd
> > wrote:
> > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar
> > > wrot
On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario wrote:
> On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote:
> > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote:
> > > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote:
> > > > On Tue, Nov 7,
On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk wrote:
> On 11/08/2017 07:34 AM, Eric Rescorla wrote:
>
>
>
> On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos
> wrote:
>
>> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote:
>> >
>> >
>
On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:
>
> Hi all,
>
> I think Flemming has expressed our points well. But I think we are losing
> sight of the purpose of the draft: this is what industry is doing today in
> response to requirements; whether imp
Initial inspection suggests that NSS behaves the same way, so I would be
fine with this change.
-Ekr
On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin
wrote:
> I think this change is a good idea.
>
> Our implementation actually does this already anyway. We are happy to
> continue servicing write
Please.
-Ekr
On Sat, Nov 11, 2017 at 5:24 PM, David Schinazi wrote:
> Thanks for checking gents!
>
> Would you like me to send a PR?
>
> David
>
>
> On Nov 12, 2017, at 09:13, Eric Rescorla wrote:
>
> Initial inspection suggests that NSS behaves the same way,
I already have a conflict for this, so I will not be attending.
-Ekr
On Mon, Nov 13, 2017 at 3:57 AM, Darin Pettis wrote:
> Sean - thank you for the update and options on rooms.
>
> Ben and Brett - which room should we meet in?
>
> Initially opposed to encrypting SNI as it appears to break man
On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario wrote:
> On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> > Hello all,
> >
> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
> did.
> > I believe that has issues and this might be the right time to fix them.
On Mon, Nov 13, 2017 at 2:38 PM, Hubert Kario wrote:
> On Monday, 13 November 2017 13:25:07 CET Eric Rescorla wrote:
> > On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario
> wrote:
> > > On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> > > > Hel
In Prague, we discussed moving server_certificate_type to EE, so that all
the
certificates in the server's Certificate message had to be of the same type.
I don't think anyone objected and this is implemented in PR#1093.
I don't plan to discuss this on Thursday. Unless someone objects, I'll just
m
I don't think that this is the right answer.
Let's separate out the question of (a) what people need to support and (b)
what the code points mean. (b) needs to be unambigous, as that's the point
of the extension and this PR actually makes it explicitly unambigous.
With that said, there seem to be
ding a ClientHello you did
> not produce, you MUST NOT process the response in any way. It will contain
> incompatible messages in the future. Alas, reality shows that the network
> did not observe these rules.
>
> On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura tapio.sok...@iki.fi&
Hi folks,
As I mentioned last week, we will be testing the changes in PR#1091 in
Firefox. Here's an update on that. We are doing two tests:
- The original Google test ("7e02") which is (mostly) PR#1091 applied
to draft-18, using Firefox Beta.
- draft-22 (as soon to be published) using Firefox
I'm pretty sure record_sequence_number is correct. The MSN is always 0 for
HVR and 1 for SH,
-Ekr
On Mon, Nov 27, 2017 at 7:43 PM, RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC6347,
> "Datagram Transport Layer Security Version 1.2
22 will be out in the next day or two. Just cleaning up the last few PRs.
-Ekr
On Tue, Nov 28, 2017 at 12:45 PM, Ilari Liusvaara
wrote:
> On Fri, Nov 24, 2017 at 12:32:15PM -0800, Eric Rescorla wrote:
> > Hi folks,
> >
> > - draft-22 (as soon to be published)
Hi folks,
I have just submitted draft-22. This includes all the changes we discussed
in Singapore. For convenience, the change log is attached at the end of this
message.
I elected not to merge either of the PSS PRs. I'll be sending a proposal
to the list for how to resolve this in the next day o
I'm going to make the DTLS draft numbers aiign with the TLS draft numbers,
so you're going to receive a bunch of bogus notifications, terminating in a
real DTLS 1.3-22.
Apologies for the inconvenience.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.
On Fri, Dec 1, 2017 at 6:47 AM, R du Toit wrote:
> I want to provide some feedback that might be useful to the TLS WG:
> Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org
> is triggering an interesting failure in at least one middlebox.
>
>
>
> The middlebox in question supp
On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley wrote:
> At the bottom of page 136, the current draft says:
>
>Note: TLS does not currently permit the server to send a
>certificate_request message in non-certificate-based handshakes
>(e.g., PSK). If this restriction were to be relaxed
t;>
>>
>> From: Andrei Popov
>> Sent: Wednesday, November 22, 2017 11:22:23 AM
>> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
>> Cc: tls@ietf.org; Tapio Sokura
>> Subject: RE: [TLS] PR#1091: Changes to
Hi folks,
I've put together a PR that attemps to address the PSS issue.
See:
https://github.com/tlswg/tls13-spec/pull/1114
Because there are platforms which don't have any support for PSS in
the cert validator, at all, it seems like we MUST be able to express
the following:
1. I accept PSS in
Hi folks,
I now have some preliminary numbers to share with the group based on
our Firefox experiments. The executive summary is that our data
confirms Google's results. More detail below.
EXPERIMENTAL DESIGN
This is a forced experiment in which each client tries all the
variants. The experiment
On Tue, Dec 5, 2017 at 1:35 PM, Eric Rescorla wrote:
> Hi folks,
>
> I now have some preliminary numbers to share with the group based on
> our Firefox experiments. The executive summary is that our data
> confirms Google's results. More detail below.
>
>
> EXPERIMEN
I would cite:
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/
(the slides, which include David's data)
https://www.ietf.org/mail-archive/web/tls/current/msg25091.html (my email
from yesterday)
-Ekr
On Wed, Dec 6, 2017 at 3:35 PM, Peter Wu wrote:
> Hi,
>
> The
On Fri, Dec 8, 2017 at 10:49 AM, Joseph Birr-Pixton
wrote:
> Hello,
>
> Draft 22 says:
>
> An implementation may receive an unencrypted record of type
> change_cipher_spec consisting of the single byte value 0x01 at any
> time during the handshake and MUST simply drop it without further
>
I'm not quite following how this helps. It's true that if SHA-256 is
broken, we're in serious trouble, but that's largely because of the fact
that that's what people's certificates have, so clients really can't refuse
to support SHA-256 certificates. So, how does adding new algorithms help?
(That's
On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote:
> We can force a rotate of all certs in 90 days, and I don't think most
> people will notice.
>
Unfortunately, there are plenty of longterm certificates with lifetimes >>
90 days.
-Ekr
>
> On Fri, Dec 15, 2017
On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara
wrote:
> On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote:
> > I'm not quite following how this helps. It's true that if SHA-256 is
> > broken, we're in serious trouble, but that's largely becau
On Mon, Dec 18, 2017 at 11:35 AM, David Benjamin
wrote:
>
>
> The web interface on some Canon printers breaks with 1.3-capable
> ClientHello messages. We have purchased one and confirmed this with a
> PIXMA MX492. User reports suggest that it also affects PIXMA MG3650
> and MX495 models. It poten
Hi folks,
Here are the results of our experiment with Firefox Nightly (draft-22)
against Facebook.
EXPERIMENTAL DESIGN
This is a forced experiment in which each client tries all the
variants. The experiment is deployed via a system add-on (a remotely
deployable, centrally managed piece of JavaScr
PR:
https://github.com/tlswg/tls13-spec/pull/1128
I'll merge this next week, barring strong objection.
-Ekr
On Tue, Dec 19, 2017 at 8:28 AM, Adam Langley
wrote:
> On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>> I'm not sure I agree renumbering is th
Good catch. Thanks.
-Ekr
On Wed, Dec 27, 2017 at 10:35 AM, Ilari Liusvaara
wrote:
> On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote:
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/1128
> >
> > I'll merge this next week, barring strong obje
On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell wrote:
> Consider the scenario where a server is operating statelessly (i.e.
> using the cookie extension) and a client is operating in middlebox
> compat mode.
>
> In that case the client sends an initial ClientHello and receives a
> ServerHello(HRR
On Thu, Dec 28, 2017 at 12:54 AM, Matt Caswell wrote:
>
>
> On 27/12/17 19:33, Eric Rescorla wrote:
> >
> >
> > On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell > <mailto:m...@openssl.org>> wrote:
> >
> > Consider the scenario where a serv
On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell wrote:
>
>
> On 28/12/17 12:28, Eric Rescorla wrote:
> > I think it would be helpful
> > to be more explicit in the text if that is the case, i.e. identify
> the
> > first point in the handshake and the last
On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell wrote:
>
>
> On 28/12/17 17:42, Eric Rescorla wrote:
> >
> >
> > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 28/12/17 12:28,
On Thu, Dec 28, 2017 at 10:02 AM, Matt Caswell wrote:
>
>
> On 28/12/17 17:55, Eric Rescorla wrote:
> >
> > On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 28/12/17 17:42, Eric Res
Yes, that is correct
On Tue, Jan 2, 2018 at 9:06 AM, Short, Todd wrote:
> Question on Post-Handshake Authentication (PHA):
>
> PHA can occur multiple times over a connection. The description for the
> "Handshake Context” is as follows (4.4):
>
>| ||
A similar idea was proposed a while back, albeit with simpler semantics:
https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00
Discussion here:
https://www.ietf.org/mail-archive/web/tls/current/msg20264.html
I'm not really enthusiastic about any of these ideas for any of the
adminis
On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk wrote:
> Hello,
> Thank You for reviewing my email.
>
> W dniu 02.01.2018 o 20:37, Eric Rescorla pisze:
> > A similar idea was proposed a while back, albeit with simpler semantics:
> >
> > https://tools.ietf.org
On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jończyk wrote:
> CCing Ted Lemon as the author of previous
> proposition.
>
> W dniu 02.01.2018 o 21:20, Eric Rescorla pisze:
> > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk > <mailto:mat.jonc...@o2.pl>> wrote:
>
I have several comments:
- This is almost entirely out of scope for TLS, so you should start with
CAPPORT. If they're interested, then we can discuss the code point
assignment in TLS.
- You point #2 would effectively require either changes to the browser or
CA issuance policies (the BRs would pro
On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk wrote:
> W dniu 03.01.2018 o 14:19, Eric Rescorla pisze:
> > I have several comments:
> >
> > - This is almost entirely out of scope for TLS, so you should start with
> > CAPPORT. If they're interested, th
On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk wrote:
> W dniu 03.01.2018 o 16:28, Eric Rescorla pisze:
> >
> >
> > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > <mailto:mat.jonc...@o2.pl>> wrote:
> >
> > W dniu 03.01.2018 o 14:19, Eric Resc
No, just forgetting we were working in hex I think it would be fine to
change.
-Ekr
On Wed, Jan 3, 2018 at 5:04 PM, Martin Thomson
wrote:
> rsa_pss_pss_sha256(0x0809),
> rsa_pss_pss_sha384(0x0810),
> rsa_pss_pss_sha512(0x0811),
>
> 0x080a is the next value...
>
> __
On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk wrote:
> W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze:
> > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote:
> >> Judging from TLS1.3's problems with middleboxes, content filtering
> isn't so
> >> rare, especially in the corporate world.
> >>
> >> T
On Thu, Jan 4, 2018 at 6:43 AM, Mateusz Jończyk wrote:
> W dniu 04.01.2018 o 15:22, Eric Rescorla pisze:
> >
> >
> > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk > <mailto:mat.jonc...@o2.pl>> wrote:
> >
> > W dniu 03.01.2018 o 18:05, Benjamin
On Thu, Jan 4, 2018 at 7:22 AM, Mateusz Jończyk wrote:
> W dniu 04.01.2018 o 16:00, Salz, Rich pisze:
> >
> >>Yes, at least in corporate environments, parental control solutions,
> etc.
> > This will give a more understandable message to the user.
> >
> >
> > But as others have pointed ou
Hi Colm,
Thanks for your note. This seems straightforward to handle before IETF-LC.
Maybe something like:
"Note: many application layer protocols implicitly assume that replays are
handled at lower levels. Tailure to observe these precautions may exposes
your application to serious risks which ar
On Thu, Jan 18, 2018 at 3:29 AM, Matt Caswell wrote:
> The specification of the new signature_algorithms_cert seems somewhat
> lacking to me. There is very little description about how it should be
> interpreted. About the best I can get from the spec is this:
>
>The "signature_algorithms_cer
Thanks. These are good points. I would welcome a PR.
On Thu, Jan 18, 2018 at 10:21 AM, R du Toit wrote:
> Issue#1: Section "4.1.3 Server Hello" currently states:
>
> *extensions A list of extensions. The ServerHello MUST only include
> extensions which are required to establish the cryptograph
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
I am for this change.
-Ekr
On Wed, Feb 7, 2018 at 12:33 PM, Sean Turner wrote:
> All,
>
> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs
> to confirm that draft-ietf-tls-record-limit should change
> max_fragment_length [1] from “Yes” in our soon to be created Recomm
On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>>
>
> Thanks Eric for your detailed r
Yeah this doesn't seem unreasonable
-Ekr
On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni
wrote:
>
>
> > On Feb 8, 2018, at 9:49 AM, Eric Rescorla wrote:
> >
> >> This depends on the mode of DANE in use (i.e. the Certificate Usage
> >> field of the
On Mon, Feb 12, 2018 at 6:10 AM, Hubert Kario wrote:
> Rules for CCS messages in record layer are missing, allowing in theory
> sending
> multiple CCS messages in a single record layer
>
> I've proposed a PR that requires the same kind of processing rules for CCS
> and
> Alert messages: https://g
On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk wrote:
> On 02/21/2018 05:46 AM, Hubert Kario wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> >> The IESG has received a request from the Transport Layer Security WG
> (tls)
> >> to consider the following document: - 'The Trans
On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote:
> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > The IESG has received a request from the Transport Layer Security WG
> (tls)
> > to consider the following document: - 'The Transport Layer Security (TLS)
> > Protocol Version 1.3'
this
one.
Thanks,
-Ekr
On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote:
> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote:
> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > >
On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote:
> Sorry for my belated follow-up. Was temporarily overwhelmed by the
> day job ..
>
>
> On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote:
> > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote:
> >
> >
On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters wrote:
> On Thu, 8 Feb 2018, Viktor Dukhovni wrote:
>
> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is st
I think this is the right answer.
-Ekr
On Sun, Feb 25, 2018 at 5:39 PM, Martin Thomson
wrote:
> Out of the secdir review (thanks again Alan!), I realized that the
> draft never actually said this:
>
>PMTU governs the size of UDP datagrams, which limits the size of
> records, but
>does
On Mon, Feb 26, 2018 at 7:48 AM, Alan DeKok
wrote:
> On Feb 25, 2018, at 8:39 PM, Martin Thomson
> wrote:
> >
> > Out of the secdir review (thanks again Alan!), I realized that the
> > draft never actually said this:
> >
> > PMTU governs the size of UDP datagrams, which limits the size of
> re
On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos
wrote:
> The TLS draft after version -21 requires TLS1.3 servers to negotiate
> pre-TLS1.3 versions with a new, mechanism. The document states:
>
>"If this extension is present, servers MUST ignore the
>ClientHello.legacy_version val
On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin
wrote:
> FWIW, this was BoringSSL's interpretation as well. We don't consider
> supported_versions an acceptable TLS 1.2 (or earlier) ServerHello
> extension. I generally agree that we shouldn't add new unnecessary
> combinations.
>
So, I think the
Hi Kenny,
Yes, this is something we are aware of. Here's the relevant text from the
document:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.appendix.E.3
I don't think we're likely to change the protocol, but if you have some
proposed text
that you think would be informative abo
On Thu, Mar 1, 2018 at 5:12 PM, Martin Thomson
wrote:
> On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
> wrote:
> > You could of course check from the front of the plaintext, keeping every
> > non-zero value:
> >
> > char ptype = 0;
> > for (i = 0; i < plaintext_len; i++)
> > if pl
On Fri, Mar 2, 2018 at 12:21 AM, Nikos Mavrogiannopoulos
wrote:
> On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote:
> >
> > I believe you are misinterpreting the text, but agree that it could
> > be
> > made more clear.
> >
> > Suppose that the ClientHello includes a supported_versions
>
Hi folks,
This is way outside the range of my DISCUSS, so maybe we should change the
thread title.
Paul, can you walk me through the security value of a proof of nonexistence
here? Perhaps describe an attack that it stops.
-Ekr
On Sat, Mar 3, 2018 at 7:09 PM, Paul Wouters wrote:
> On Thu, 1
On Sun, Mar 4, 2018 at 4:12 PM, Fossati, Thomas (Nokia - GB/Cambridge) <
thomas.foss...@nokia.com> wrote:
> On 04/03/2018, 23:12, "Martin Thomson" wrote:
> > We are about to remove that bit from the QUIC packet. I don't see any
> > advantage in adding it here.
> >
> > Can you explain in more det
Hi folks,
Here's another entry in the DH-only pile.
I've just posted:
draft-rescorla-tls13-semistatic-dh-00
This implements a semi-static DH exchange mostly borrowed from
OPTLS [0]. There are obviously connections with draft-putman, but
this is more oriented towards implementing a 1-RTT style
Without taking a position on the security matter: this has been part of the
TLS design for 20+ years, and therefore has had multiple LCs and WG and
IETF consensus, so it would take a pretty strong set of arguments to change
now. I've debugged a lot of TLS interop issues, and as a practical matter,
On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov
wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-tls-tls13-26: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
On Wed, Mar 7, 2018 at 7:27 AM, Alexey Melnikov
wrote:
> Hi Ekr,
>
> On Wed, Mar 7, 2018, at 2:16 PM, Eric Rescorla wrote:
>
>
>
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov
> wrote:
>
> Alexey Melnikov has entered the following ballot position for
>
Well, this is like TCP in that respect. You send close_notify and then you
either stop reading off of or close the TCP socket.
-Ekr
On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan wrote:
> Hi,
>
> Per TLS 1.3 draft (Section 6.1, Closure Alerts), the close_notify alert is
> used to notify the recipi
> 1) I'm a bit uncertain if obsoleting is the right approach as many
> other protocols usually do not obsolete older versions. However, I
> understand that this has been the approach TLS has previously taken
> and is supported by the way the document is written.
Well:
https://www.ietf.org/iesg/sta
Hi Adam,
Thanks for your comments.
I'm going to let the Chairs handle the Abstract one.
Responses below (I'm ignoring a bunch which I just agree with).
> §4.2.1:
>
> > TLS SHOULD support TLS 1.2. Servers should be prepared to receive
> > ClientHellos that include this extension but do not
On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:
> > > Still, I find it
> > > especially confusing that also two TLS1.2 extensions are deprecated
> > > which are not needed with TLS1.3 anymore but still probably valid to
> > > be used with TLS1.2, right?
> >
>
On Wed, Mar 7, 2018 at 4:39 PM, Sean Turner wrote:
>
>
> > On Mar 7, 2018, at 16:35, Ben Campbell wrote:
> >
> >
> >
> >> On Mar 7, 2018, at 2:49 PM, Sean Turner wrote:
> >>
> >>
> >>
> >>> On Mar 6, 2018, at 12:27, Ben Campbell wrote:
> >>>
> >>> Ben Campbell has entered the following ballot
On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins <
spencerdawkins.i...@gmail.com> wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-tls-tls13-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in th
key which could later be used in a draft-putman
> exchange; however, the natural continuation would be to use a resumption
> PSK, so this would only be useful if there were a long gap between session,
> which seems unlikely.
>
>
>
> Regards,
>
> Tony
>
>
>
> *From
See issue #1166.
The current text neither allows nor prohibits the same OID appearing twice.
We should do one or the other.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
can be used..."
is about.
> §11: The IANA considerations have a number of constructions similar to
"SHALL update/has updated".
> Is that text expected to collapse to "has updated" at some point?
Yes. RFC-Ed typically does this.
-Ekr
On Wed, Mar 7, 2018 at 5:47 PM,
On Wed, Mar 7, 2018 at 6:16 AM, Eric Rescorla wrote:
>
>
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-tls-tls13-26: Discuss
>>
>> When responding, please keep t
On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins
wrote:
> Stephen (and TLS group)
>
> We need to look at the bigger picture.
>
> The TLS working group has been concentrating on making the Internet secure
> for the individual user.We feel that there is also an underlying
> motivation to help the
On Fri, Mar 16, 2018 at 4:19 PM, Matt Caswell wrote:
> What is reasonable behaviour for a client to do with any tickets it has
> previously received following a key update or a post-handshake
> authentication? Should those old tickets be now considered out-of-date
> and not used?
>
There is no g
r 18, 2018 at 1:20 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title : The Transport Layer Security (TLS) Protocol
> Ver
After discussion with the chairs and the AD, I have opted to just add a
section
that explains the attack. I just merged that (but managed not to get it
into -27
due to fumble fingering).
-Ekr
On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario wrote:
> When the server supports externally set PSKs th
On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > >
> > >
> > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > > On Thu, Mar 15, 2018 at 12:25:38P
On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik wrote:
> Hi Sean:
>
> Quick question: does "closing the registry" not contradict catering
> towards crypto agility? What happens if, say, one wishes to add another
> signature scheme, besides Ed25519, to the mix. If there is no private
> field, does th
s should we mark 224-255 as deprecated
> in these two registries?
>
> On 3/20/2018 10:54 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik
> wrote:
>
>> Hi Sean:
>>
>> Quick question: does "closing the registry" n
501 - 600 of 1635 matches
Mail list logo
