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 the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
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 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 position for
>>> draft-ietf-tls-tls13-26: Yes
>>>
>>> When responding
> 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 position for
>> draft-ietf-tls-tls13-26: Yes
>>
>> When responding, please keep the subject line intact and reply to all
>> email addr
Hi David,
The case I can think of now is the START TLS protocols (Opportunistic
TLS). But looks like these protocols need to use an existing plain-text
socket, and then establish a TLS connection over it, and will never go back
to plain-text again. Maybe, for START TLS protocols, closing TLS
con
> On Mar 6, 2018, at 12:27, Ben Campbell wrote:
>
> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-tls13-26: Yes
>
> 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
> in
Hi Xuelei,
Can you elaborate on what proxy protocol you're using that can reuse the TCP
connection for follow on connections, and what semantics it has?
As far as I know, SOCKS and HTTP CONNECT don't support this.
Additionally, the close_notify alerts are sent encrypted so the proxy wouldn't
be
Mirja,
On Wed, Mar 7, 2018 at 2:03 PM, Eric Rescorla wrote:
>
>
> On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF)
> 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 prob
> On Mar 7, 2018, at 03:58, Adam Roach wrote:
>
> Adam Roach has entered the following ballot position for
> draft-ietf-tls-tls13-26: Yes
>
> 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
> introd
On 3/7/18 12:58 PM, Eric Rescorla wrote:
> As a rule of thumb, "that" is used to start restrictive clauses
("Two doors
> are in front of you. The door that is on the right leads outside"),
while
> "which" is used to start non-restrictive clauses ("The only door in
the room,
> which is made of w
Hi David,
This issue happens when the TLS connection is established/layered on an
existing TCP connection. For example:
1. A client connects to a proxy
2. The client establishes a TLS 1.3 connection to a server via the proxy.
3. The server delivers 2+ records to the client.
4. The client receiv
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?
> >
>
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
Hi,
see below
> Am 07.03.2018 um 19:05 schrieb Eric Rescorla :
>
> > 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 suppor
Thanks for your review, Mirja. I will just add one comment inline
from WG discussion and consensus.
On Wed, Mar 7, 2018 at 1:05 PM, Eric Rescorla wrote:
>> 1) I'm a bit uncertain if obsoleting is the right approach as many
>> other protocols usually do not obsolete older versions. However, I
>>
Hi Xuelei,
Do you have an example for when you would need to gracefully close the read
side?
If you're downloading a 10GB video and the user cancels the download, you can
simply tear down the TCP connection by sending a RST.
The benefit of having a graceful read close would be for the server to
> 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
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
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
> draft-ietf-tls-tls13-26: Discuss
>
> Whe
Hi,
Per TLS 1.3 draft (Section 6.1, Closure Alerts), the close_notify alert is
used to notify the recipient that the sender will not send any more
messages on this connection. And this does not have any effect on its read
side of the connection. I think it means that after sending the
close_noti
+1. If anything, the existing "buggy implementation" alert codes should get
folded together. (But I don't think it's worth making that change at this
stage either.) E.g. decode_error vs illegal_parameter vs
unexpected_message are rather useless distinctions and trying to get them
"right" adds compl
Mirja Kühlewind 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 the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
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
>> draft-ietf-tls-tls13-26: Discuss
>>
>> When responding, please keep the subject line intact and r
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
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 this
introductory paragraph, however.)
Please refer to https://w
On Wednesday, 21 February 2018 15:31:33 CET Eric Rescorla wrote:
> i think your general point is sound here, but I'll nitpick the statement
> that
> "if the server recognises an identity but is unable to verify corresponding
> binder".
>
> 1. The server only picks one identity so you if you send A
Adam Roach has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes
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 refer to https://www.ietf.o
27 matches
Mail list logo
