Re: [rtcweb] DTLS version

Shijun Sun <shijuns@microsoft.com> Mon, 07 July 2014 21:30 UTC

Return-Path: <shijuns@microsoft.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD91B28B6 for <rtcweb@ietfa.amsl.com>; Mon, 7 Jul 2014 14:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spPx0pjurCFd for <rtcweb@ietfa.amsl.com>; Mon, 7 Jul 2014 14:30:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D701D1B2933 for <rtcweb@ietf.org>; Mon, 7 Jul 2014 14:29:54 -0700 (PDT)
Received: from BLUPR03MB405.namprd03.prod.outlook.com (10.141.78.15) by BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 21:29:52 +0000
Received: from BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) by BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 21:29:53 +0000
From: Shijun Sun <shijuns@microsoft.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] DTLS version
Thread-Index: AQHPlpICeV5LRgJomEee9jrC1yXJQ5uN+SAAgAAOY4CAAJwqgIAA7SgAgAAmEYCAAJ3nAIAAFyaAgAACUACAAAJLAIAErRgw
Date: Mon, 07 Jul 2014 21:29:51 +0000
Message-ID: <f46d1e4a7dc64267926d6e3e05e7196c@BLUPR03MB405.namprd03.prod.outlook.com>
References: <A963F527-57EB-4617-9583-6C0D63DDE4BD@lurchi.franken.de> <CAOW+2dvgg3zMU0C_EjozRnEEs9BmSy2k0u2PKExb3AeCF6in=Q@mail.gmail.com> <C52F606C-C7E3-4AF8-B249-07C16A474F52@lurchi.franken.de> <CABkgnnXszLWwXgfg=TOHuxrnnQMy3QBaFKS2SC+eOHiC90cFoQ@mail.gmail.com> <DBE402B8-82FF-41A8-A971-9BB71D9A4830@lurchi.franken.de> <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CABkgnnWBeeSDoeHDkbjGEwvpcJ+Ld6q1Fs_Fwckp3oW_Hzmcew@mail.gmail.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CABcZeBMTJpmriEnNNYwtah8ABjUvZMuuO2xHJ33Jc6_A1XsrMg@mail.gmail.com> <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> <CABcZeBOyXZ28NBHpWSHXNL=g+6d=XL_2UCm7EssKptyfEy=pvw@mail.gmail.com> <C219E7F1-4F2C-448F-969C-F4CDD3B019C3@lurchi.franken.de>
In-Reply-To: <C219E7F1-4F2C-448F-969C-F4CDD3B019C3@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.160.140]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 02652BD10A
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199002)(189002)(479174003)(377454003)(51704005)(24454002)(107046002)(46102001)(561944003)(19580405001)(93886003)(66066001)(74316001)(4396001)(77982001)(76576001)(85306003)(83322001)(105586002)(76482001)(79102001)(31966008)(20776003)(21056001)(106116001)(101416001)(99396002)(81542001)(76176999)(54356999)(81342001)(92566001)(74662001)(2656002)(95666004)(80022001)(85852003)(99286002)(106356001)(50986999)(83072002)(15975445006)(33646001)(86612001)(64706001)(87936001)(86362001)(74502001)(19580395003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB408; H:BLUPR03MB405.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n8c6G3VCX2y9fCzOFqk4JsmbeWw
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DTLS version
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 21:30:21 -0000

There seems a preference on supporting DTLS 1.0 due to the widespread adoption.  There is also a desire of supporting ECDHE when ECC is on a Standards Track.  Hope we could reach a consensus in Toronto.  

To keep the discussions going, here is a proposal with a specific cipher suite based on DTLS 1.0.  

    All implementations MUST implement the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
    based on DTLS 1.0 with P256 as the curve to be used with ECDHE and ECDSA.  The Implementations 
    MAY advertise additional cipher suites based on DTLS 1.0 and/or DTLS 1.2 definitions, for example, 
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with P256.

We could keep DTLS 1.2 as an optional implementation decision for now and make that (and some corresponding new cipher suites) as required in the future.

Thoughts?

Best, Shijun 

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael Tuexen
Sent: Friday, July 4, 2014 2:28 PM
To: Eric Rescorla
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] DTLS version

On 04 Jul 2014, at 23:19, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> 
> On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> On 04 Jul 2014, at 21:48, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> > I made this change in the current draft at:
> >
> > https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd36
> > 7dff8d4d16f7ec435fa663
> If implementations MUST implement both DTLS 1.0 and 1.2, when will 
> they use 1.0? Wouldn't they always use DTLS 1.2?
> 
> There are non-RTCWEB implementations of these protocols.
OK. Any suggested test for the SCTP over DTLS spec? It currently says MUST be based on DTLS 1.0 (as you suggested).

Best regards
Michael
> 
> -Ekr
>  
> Best regards
> Michael
> >
> > Note that the TLS WG is currently discussing whether to bring ECC onto Standards Track.
> > If they do, we probably want ot require support of ECDHE. We should discuss in YYZ.
> >
> >
> >
> > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
> > This is the direction I am tending in as well.
> >
> > Although what or if the second statement needs from RFC 2119 language would need to be debated.
> >
> > Obviously, new versions are not being put out there just to make it look like the WG is performing. In any referencing (not just this issue), I would need a good technical reason why the latest version cannot be made the normative reference. I am not seeing that at the moment.
> >
> > There is always be non-conforming equipment on the market (as an example look at the number of SIP implementations that still use UDP for large messages, or that can at least be configured that way). Just because we mandate 1.2 does not mean that everyone will conform from day 1, but at least a marker is established for what should be addressed if interoperability issues are identified.
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald 
> > > Alvestrand
> > > Sent: 04 July 2014 09:07
> > > To: rtcweb@ietf.org
> > > Subject: Re: [rtcweb] DTLS version
> > >
> > > On 07/03/2014 07:58 PM, Martin Thomson wrote:
> > > > On 3 July 2014 01:39, DRAGE, Keith (Keith) 
> > > > <keith.drage@alcatel-lucent.com> wrote:
> > > >> Can someone elaborate what this massive apparent step
> > > change is from 1.0 to 1.2?
> > > > Actually, it's not a massive step.  TLS 1.2 (DTLS 1.2
> > > depends on this,
> > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't 
> > > > require their use, so you can pretty much just bump the version 
> > > > number and advertise 1.2.  That's exactly what we did with NSS, 
> > > > though NSS already supports TLS 1.2.
> > > >
> > > > That said, I agree with Jim about 1.0.  There's enough 1.0
> > > out there
> > > > now to make mandating 1.2 - as much as I might prefer that
> > > - a little
> > > > too aggressive.
> > > >
> > > >> Will those implementations that choose to stay with 1.0
> > > still interwork with 1.2?
> > > > That depends.  We could say "MUST NOT negotiate 1.0", which 
> > > > would prevent that.  I don't think that we're there.
> > >
> > > Sounds to me like MUST implement 1.2 (in order to move forward), 
> > > MUST accept 1.0 (in order to not lose the long tail).
> > >
> > > >
> > > > _______________________________________________
> > > > rtcweb mailing list
> > > > rtcweb@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

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