On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk <ka...@mit.edu> 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 0-RTT, and if
>> others want to weigh in they can. I'll state my own position at the bottom.
>
> Thanks for this summary and review; I think it's well-said.

Yes, agreed and  also thank you for your work on this important topic
to improve the security for 0-RTT and implementing the mitigation
techniques.

>
>> Broadly, I think there are three issues with 0-RTT:
>>
> [...]
>> At the same time though, most vendors have stated that they don't plan to
>> do that and instead have designed around limited replay time windows,
>> non-transactional strike registers, and non-forward secure tickets. This is
>> what I expect to see deployed, and already see with some TLS1.3 deployment
>> experiments.  TLS1.3 could be more restrictive here; limiting the size of
>
> 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 of where to set our expectations.  Though of course I do not
> insist that you assemble one, and I do not want my comment to be
> seen as detracting from your review overall.

And this can and should be done separate from the draft publication
process.  I'm pretty sure that's what Ben intended as we don't want to
hold this up any more.

>
>> session tickets to smaller than the size of session state would effectively
>> forbid any kind of session encoding which would force the issue, but
>> several vendors are against it because it doesn't align with current
>> practices and it incurs the cost of server-size caching. For balance, in
>> the last year I have heard from most vendors that they do plan to implement
>> some anti-replay mitigation though, beyond the simple time-windowing, which
>> goes a way to protecting users from throttle limits.
>>
> [...]
>>
>> But my more important reason for supporting is that overall TLS1.3 is much
>> much better than TLS1.2, including in regards to forward-secrecy, which is
>> now guaranteed for all non-0RTT data. I still believe that it will
>> meaningfully increase the overall security posture for the internet, and
>> I'm super excited to get it out and for users to be getting the benefits.
>> TLS has always been a bit of a mess, it's not as clean as something
>> designed by a single voice focused on modern cryptographic best-practices,
>> but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things
>> can't be improved further, and delay inflicts 1.2 and lower versions on
>> users for even longer. So let's go!
>
> Well said!

Agreed.  I didn't mean to kick off a new thread on this, I was just
using it as an example of where I'll uphold the WG decision and
support it fully in IESG discussions in my role as AD.

Thanks again for your and others work to improve the 0-RTT situation!

Best regards,
Kathleen
>
> -Benjamin
>
>>
>> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>> > 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
>> > ServerHello decision is from the WG, I will support that decision.
>> > The ServerHello decision doesn't really fall into the, "arms race" as
>> > you put it.  More on that in another thread.
>> >
>> > Best regards,
>> > Kathleen
>> >
>> > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_...@hotmail.com>
>> > wrote:
>> > > I wonder what is IESG's opinion on the TLS arms race with middleboxes.
>> > > Yes, I am talking about moving the version number in the ServerHello.
>> > >
>> > > ________________________________________
>> > > From: TLS <tls-boun...@ietf.org> on behalf of The IESG <
>> > iesg-secret...@ietf.org>
>> > > Sent: Thursday, February 15, 2018 1:13:48 PM
>> > > To: IETF-Announce
>> > > Cc: draft-ietf-tls-tl...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
>> > > Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport
>> > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
>> > >
>> > >
>> > > 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'
>> > >   <draft-ietf-tls-tls13-24.txt> as Proposed Standard
>> > >
>> > > The IESG plans to make a decision in the next few weeks, and solicits
>> > final
>> > > comments on this action. Please send substantive comments to the
>> > > i...@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may
>> > be
>> > > sent to i...@ietf.org instead. In either case, please retain the
>> > beginning of
>> > > the Subject line to allow automated sorting.
>> > >
>> > > Abstract
>> > >
>> > >
>> > >    This document specifies version 1.3 of the Transport Layer Security
>> > >    (TLS) protocol.  TLS allows client/server applications to communicate
>> > >    over the Internet in a way that is designed to prevent eavesdropping,
>> > >    tampering, and message forgery.
>> > >
>> > >
>> > >
>> > >
>> > > The file can be obtained via
>> > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>> > >
>> > > IESG discussion can be tracked via
>> > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/
>> > >
>> > > The following IPR Declarations may be related to this I-D:
>> > >
>> > >    https://datatracker.ietf.org/ipr/2900/
>> > >
>> > >
>> > >
>> > > The document contains these normative downward references.
>> > > See RFC 3967 for additional information:
>> > >     rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2
>> > (Informational - IETF stream)
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > TLS mailing list
>> > > TLS@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/tls
>> > >
>> > > _______________________________________________
>> > > TLS mailing list
>> > > TLS@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/tls
>> >
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Kathleen
>> >
>> >
>>
>>
>> --
>> Colm
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to