Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Benjamin Kaduk
On Mon, Feb 19, 2018 at 03:31:40PM -0500, Kathleen Moriarty wrote: > On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk wrote: > > > > I don't disagree. It might be helpful to have a conslidated list of > > references for the vendor statements, so we can get a more clear > > picture

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Martin Thomson
(+tls@) This is a good question Jim and one that I thought through during implementation, but failed to capture in the doc. Basically, there is no way to validate the extension if the client includes an unknown version of TLS or an extension that it doesn't understand. A client can know because

Re: [TLS] AD review of draft-ietf-tls-record-limit

2018-02-19 Thread Kathleen Moriarty
Hi Martin, Thanks for your response. I just wanted to check on this and not hold up the draft in the process. Thanks for also addressing Jim's question. Best regards, Kathleen On Sun, Feb 18, 2018 at 7:09 PM, Martin Thomson wrote: > I don't think that this targets a

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Kathleen Moriarty
Dear Yuhong, As the sponsoring Area Director, my job is to take the draft forward as was determined by working group consensus. Like Stephen, I'm also not particularly happy about the choice to leave in 0-RTT, but I have to support it as a WG decision. Whatever the version number in the

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Benjamin Kaduk
On 02/19/2018 04:14 AM, Martin Thomson wrote: > (+tls@) > > This is a good question Jim and one that I thought through during > implementation, but failed to capture in the doc. > > Basically, there is no way to validate the extension if the client > includes an unknown version of TLS or an

[TLS] Middlebox "arms race" WAS: Re: Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Kathleen Moriarty
Dear Yuhong, My personal opinion in the "arms race" (your phrasing, not mine), no AD hat on (as that one is to support the WG decision), is that it will continue until we really hear each other out and think more on the problems the other side is trying to solve. Perhaps there are ways to meet

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Jim Schaad
Martin, I think that the wording I would prefer would be along the lines of A server MUST NOT error on the value of the extension when a higher TLS version is requested. The server MUST use the minimum of the requested value and the maximum value for the TLS version negotiated. A server MAY

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Ilari Liusvaara
On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote: > Martin, > > I think that the wording I would prefer would be along the lines of > > A server MUST NOT error on the value of the extension when a higher > TLS version is requested. The server MUST use the minimum of the > requested

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Jim Schaad
> -Original Message- > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] > Sent: Monday, February 19, 2018 9:51 AM > To: Jim Schaad > Cc: 'Martin Thomson' ; tls@ietf.org; draft-ietf- > tls-record-li...@ietf.org > Subject:

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Benjamin Kaduk
On 02/19/2018 11:55 AM, Jim Schaad wrote: > >> -Original Message- >> From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] >> Sent: Monday, February 19, 2018 9:51 AM >> To: Jim Schaad >> Cc: 'Martin Thomson' ; tls@ietf.org;

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Ilari Liusvaara
On Mon, Feb 19, 2018 at 09:55:51AM -0800, Jim Schaad wrote: > > > > -Original Message- > > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] > > Sent: Monday, February 19, 2018 9:51 AM > > To: Jim Schaad > > Cc: 'Martin Thomson'

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Jim Schaad
> -Original Message- > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] > Sent: Monday, February 19, 2018 9:18 AM > To: Jim Schaad > Cc: 'Martin Thomson' ; tls@ietf.org; draft-ietf- > tls-record-li...@ietf.org > Subject:

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

2018-02-19 Thread Ilari Liusvaara
On Mon, Feb 19, 2018 at 09:27:14AM -0800, Jim Schaad wrote: > > > > -Original Message- > > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] > > Sent: Monday, February 19, 2018 9:18 AM > > To: Jim Schaad > > Cc: 'Martin Thomson'

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Stephen Farrell
Just on the 0-RTT thing: As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely argued too btw.) I do believe we'll live to regret 0-RTT when implementation issues and unsuitable application uses emerge over time but neither that nor general dislike of 0-RTT are IMO sufficient reasons to

[TLS] I-D Action: draft-ietf-tls-sni-encryption-01.txt

2018-02-19 Thread internet-drafts
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 : SNI Encryption in TLS Through Tunneling Authors : Christian Huitema Eric

[TLS] Fwd: New Version Notification for draft-ietf-tls-sni-encryption-01.txt

2018-02-19 Thread Christian Huitema
The main change in the new version of this draft is the addition of "multi-protocol" requirements. Namely, hiding the SNI should also work for protocols like DTLS or QUIC. Then, it would be nice if we could also hide the ALPN, but that's somewhat less critical. After all, we could run every

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Kathleen Moriarty
On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk wrote: > Hi Colm, > > On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote: >> Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd >> like to boil down what I think are the nits and risks with

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Colm MacCárthaigh
Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd like to boil down what I think are the nits and risks with 0-RTT, and if others want to weigh in they can. I'll state my own position at the bottom. Broadly, I think there are three issues with 0-RTT: 1) The TLS 1.3

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Benjamin Kaduk
Hi Colm, On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote: > Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd > like to boil down what I think are the nits and risks with 0-RTT, and if > others want to weigh in they can. I'll state my own position at

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2018-02-19 Thread Kathleen Moriarty
Sent from my mobile device > On Feb 19, 2018, at 5:04 PM, Stephen Farrell > wrote: > > > Just on the 0-RTT thing: > > As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely > argued too btw.) > > I do believe we'll live to regret 0-RTT when implementation