Re: [TLS] TLS 1.3, how to close the read side of a connection?

David, I think this is a valid concern. It's been commented on (https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the draft has NO requirements on the underlying transport. There are potentially other transports for TLS (such as being worked by the ATLAS WG) which may not h

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

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

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

> On Mar 8, 2018, at 08:10, Eric Rescorla wrote: > > > > On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins > 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 al

[TLS] TLS@IETF101 Agenda Posted

I’ve posted the draft agendas: Monday: https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb Wednesday: https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessa spt ___ TLS mailing list TLS@ietf.org https://www.ie

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Sean, Joe, On 08/03/18 16:20, Sean Turner wrote: > I’ve posted the draft agendas: > > Monday: > https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb That includes: " TLS Vizability - Russ & Chairs - 30min - 10min draft - Russ https://datatracker.ietf.org/doc/draft-rhr

Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

Hi Ekr, Firstly, thanks for this. My primary reason for putting together draft-putman was to propose a handshake exchange which only uses a single asymmetric algorithm. If this proposal is extended to include raw public keys (I think these are already supported, but not mentioned in the text) a

Re: [TLS] TLS 1.3, how to close the read side of a connection?

Hi Tony, I agree with you, TLS should not have requirements on the underlying transport. If there is a use case that would require endpoints have a way to signal to the peer that they're done reading, I would suggest writing a draft about a new close_request alert. I personally don't think this

Re: [TLS] TLS 1.3, how to close the read side of a connection?

Sure, the requirements are: don’t close the transport until TLS says it is done. You can’t do half-duplex close with TLS. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3, how to close the read side of a connection?

Fully agree. Defer it until there is a need. -- Tony From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi Sent: 08 March 2018 17:48 To: Tony Putman Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection? Hi Tony, I agree with you, TLS should not ha

Re: [TLS] TLS 1.3, how to close the read side of a connection?

+1 On Mar 8, 2018, 12:56 PM -0500, Tony Putman , wrote: > Fully agree. Defer it until there is a need. > -- Tony > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi > Sent: 08 March 2018 17:48 > To: Tony Putman > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3, how to close the r

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Sean, Joe, WG also has this at its disposal: https://tools.ietf.org/html/draft-fenter-tls-decryption-00 Will that be discussed along with draft-rhrd-tls-tls13-visibility? Those two seem to be rather connected/dependant on each other. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 0

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Stephen, In the meeting in Prague there was interest in this problem space, but neither the consensus to accept or reject this work. The authors have revised their proposal to address some of the concerns raised by working group members and are asking to bring the new approach in front of the

Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman wrote: > Hi Ekr, > > > > Firstly, thanks for this. My primary reason for putting together > draft-putman was to propose a handshake exchange which only uses a single > asymmetric algorithm. If this proposal is extended to include raw public > keys (I th

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

On Fri, Mar 9, 2018 at 12:10 AM, Eric Rescorla wrote: >> I wondered why >> >>Newer >>clients or servers, when communicating with newer peers, SHOULD >>negotiate the most preferred common parameters. >> >> was not a MUST. > > > Ugh, this is actually not even a normative statement, It's

Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

On Mar 8, 2018, 6:25 PM -0500, Eric Rescorla , wrote: > > On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman wrote: > > > Hi Ekr, > > > > > > Firstly, thanks for this. My primary reason for putting together > > > draft-putman was to propose a handshake exchange which only uses a single > > > asymmetri

Re: [TLS] TLS@IETF101 Agenda Posted

Artyom, Thanks for mentioning the ID and you are right that draft Fenter is the supporting problem description. The reason it was written was to help folks understand why legitimate internal out-of-band decryption is still needed on data once it reaches its destination and that there isn’t a viabl

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Darin, I just asked for clarification whether it's on a TLS WG agenda for London. I'm not quite sure this is a right thread to discuss the contents of that draft. (In fact, I'm pretty sire it isn't.) | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: xima.