Re: [TLS] SPKI Fingerprints

[Daniel Migault]

Thanks for the detailed response, that is very much appreciated. When I
wrote the initial email, I had more in mind some sort of configuration - as
opposed to DANE. I agree that the use of PSKI should not cause any of the
headaches associated with pinning.

Yours,
Daniel

On Mon, Jun 13, 2022 at 11:56 AM Viktor Dukhovni 
wrote:

> On Mon, Jun 13, 2022 at 10:42:51AM -0400, Daniel Migault wrote:
>
> > I sent this question regarding the use of SPKI Fingerprints to the
> > add mailing list, but I am also eventually interested to feed backs not
> > necessarily restricted to encrypted resolvers.
> >
> > RFC 7858 (DNS over TLS) indicates the use of SPKI Fingerprints in an
> > analogous manner to that described in RFC7469 (public KEy Pinning
> extension
> > for HTTP). I am wondering if anyone is aware of implementation
> considering
> > SPKI Fingerprints for or if such usage is not something we would like to
> > recommend/deprecate.
>
> SPKI fingerprints are used in DANE, specifically either:
>
> * DANE-EE(3) SPKI(1) SHA2-256(1)/SHA2-512(2) records
> * PKIX-EE(1) SPKI(1) SHA2-256(1)/SHA2-512(2) records
>
> Since the TLSA records are published by the service operator, questions
> about stale data largely go away, modulo a small fraction of negligent
> operators (in SMTP stale TLSA records are seen for ~1% of MX hosts, but
> more importantly, only 0.0053% of DANE-enabled domains).
>
> Also, OpenSSL supports use of SPKI fingerprints for peer certificate
> verification, because "TLSA record" lookups are left up to the
> application, which feeds these into the SSL handle prior to the
> handshake.  This makes it possible to synthesise TLSA "[31] 1 [12]"
> records corresponding to an SPKI fingerprint, and use these in
> peer certificatre chain verification.
>
> Postfix, for example, has a "fingerprint" TLS "security level", in which
> the peer is authentication via a locally specified SPKI fingerprint, and
> this actually implemented on top of the OpenSSL DANE API via the above
> mentioned synthetic TLSA records.
>
> --
> VIktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] SPKI Fingerprints

[Daniel Migault]

Hi,

I sent this question regarding the use of SPKI Fingerprints to the
add mailing list, but I am also eventually interested to feed backs not
necessarily restricted to encrypted resolvers.

RFC 7858 (DNS over TLS) indicates the use of SPKI Fingerprints in an
analogous manner to that described in RFC7469 (public KEy Pinning extension
for HTTP). I am wondering if anyone is aware of implementation considering
SPKI Fingerprints for or if such usage is not something we would like to
recommend/deprecate.

Yours,
Daniel
-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] progressing draft-ietf-tls-md5-sha1-deprecate

[Daniel Migault]

Looks good to me however this still represents in my opinion an update to
5246 -- which I think is also what we want.

Yours,
Daniel

On Thu, Sep 2, 2021 at 10:37 PM Sean Turner  wrote:

> Just a reminder that sometime tomorrow I will ask for these PRs to be
> merged and a new version of the I-D be produced so that we can make
> progress.
>
> spt
>
> > On Aug 27, 2021, at 10:58, Sean Turner  wrote:
> >
> > Hi! While address the IoT Directorate comments from IETF LC, some
> addition comments have been received. I would like to address these new
> comments and get the I-D in the hands of the iESG. There were three set of
> comments:
> >
> > 1) Based on Daniels and David Benjamin’s reviews, the I-D is not as
> clear as it could be. The end result of deprecating MD5 and SHA1 is that
> signature_algorithms is always included; we should just say that. Chris has
> submitted the following PR to address this:
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/19
> > You will notice that the PR removes section 6 of the I-D; it is unclear
> how much utility there is in updating the NOTE.
> >
> > We are looking to merge this PR at the end of next week so please submit
> any comments before then.
> >
> > 2) Hannes suggested that we remove the 7525 updates text now that
> 7525bis is underway. I submitted this issue to capture the issue:
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/17
> > Peter Saint-Andre (one of the 7525bis authors) has filled the following
> issue to incorporate the text from our I-D:
> > https://github.com/yaronf/I-D/issues/245
> > Yaron has already merged the PR:
> > https://github.com/yaronf/I-D/pull/248
> > Chris has also kindly submitted this PR to remove the 7525bis-related
> text from “our" I-D:
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/18
> >
> > Again, we are looking to merge this PR at the end of next week so please
> submit any comments before then.
> >
> > 3) Hannes also had some editorial suggestions, that I created issues for:
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/16
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/15
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/14
> > These are addressed in this PR:
> > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/20
> >
> > These ought to all be non-controversial, so we will merge them sometime
> next week.
> >
> > Cheers,
> > spt (as Shepherd)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

Just to sum, up my initial comment proposed to mention as being removed
remove the texts mentioned below. Since Sean mentioned that removing a text
with MUST can be problematic, for the first text we can also just explain
that in the context of this draft, the first text ends in being some dead
code. I would be interested to understand - and only for my personal
understanding - why removing a text with MUST is harder than a text with
MAY.

My understanding is that the current proposal is to remove the second text,
and that the case of the first text has not been concluded - of course
unless I am missing something. As a result, I think I hope we can converge
for the two texts and I am fine the first text being mentioned as removed
or ending as  dead code.

 """
If the client does not send the signature_algorithms extension, the
server MUST do the following:
-  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
   sent the value {sha1,rsa}.

-  If the negotiated key exchange algorithm is one of (DHE_DSS,
   DH_DSS), behave as if the client had sent the value {sha1,dsa}.

-  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
   ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
"""


"""
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension.
"""

Yours,
Daniel

On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig 
wrote:

> I have no problem with the suggestion.
>
> A few other observations:
>
> 1. FWIW: The reference to [Wang] is incomplete.
>
> 2. The references to the other papers use the websites of the authors or
> project websites. I would use more stable references.
>
> 3. Kathleen's affiliation is also outdated.
>
> 4. Is the update to RFC 7525 relevant given that there is an update of RFC
> 7525 in progress (see
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and
> even near completion?
>
> 5. The title of the draft gives the impression that this update only
> refers to TLS 1.2 but later in the draft DTLS is also included via the
> reference to RFC 7525. Should the title be changed to "Deprecating MD5 and
> SHA-1 signature hashes in TLS/DTLS 1.2"?
>
> Ciao
> Hannes
>
> -Original Message-
> From: Iot-directorate  On Behalf Of
> Russ Housley
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Sean Turner ; IETF TLS 
> Cc: iot-director...@ietf.org;
> draft-ietf-tls-md5-sha1-deprecate@ietf.org; last-c...@ietf.org
> Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review
> of draft-ietf-tls-md5-sha1-deprecate-04
>
> >   In Section 7.1.4.1: the following text is removed:
>
>  If the client supports only the default hash and signature algorithms
>  (listed in this section), it MAY omit the signature_algorithms
>  extension.
>
> >   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?
>
> I don't see any harm.
>
> Russ
>
> --
> Iot-directorate mailing list
> iot-director...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-directorate
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Heads up on Netdev conf 0x15 - not too late to attend!

[Daniel Migault]

Hi,

For those that have not already attending Netdev, Netdev conf 0x15 has been
running since July 7 but it runs for 3 weeks but the talk sessions don't
start until Monday. As usual a lot of IETF relevant talks.
See: https://netdevconf.info/0x15/accepted-sessions.html

The fee is USD $50. Students(proof required) are 50% off.

The first 2 weeks was keynote, workshops and tutorials. You can replay all
the sessions you missed by entering the conference platform (registration
required).

The keynote was by Hari Balakrishnan, see:
https://netdevconf.info/0x15/session.html?keynote-balakrishnan

On Monday as well there will be an industry perspectives panel on smartnics
which will involve 6 vendors and an industry veteran moderating the session.

For registration go here:
https://netdevconf.info/0x15/virtual.html

Yours,
Daniel

-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

Thanks Logan for posting the new version. I am trying to summarize where we
are with version 07. I think there is one remaining concern that has not
been addressed, though it is not clear to me how we agreed to address it.

Yours,
Daniel

On Tue, May 4, 2021 at 11:17 PM Daniel Migault  wrote:

> Hi,
>
> Thanks for the update and the followup. To me the only remaining point I
> am not sure has been fully addressed is the clarification of 5246, but
> otherwise we agree on the content to be written. Please find my comments
> inline.
>
> Yours,
> Daniel
>
> On Tue, May 4, 2021 at 1:23 PM Sean Turner  wrote:
>
>> Daniel,
>>
>> Thanks for your (and the WG’s) patience on this. Responses in line.
>>
>> spt
>>
>> > On Apr 9, 2021, at 14:54, Sean Turner  wrote:
>> >> On Jan 22, 2021, at 08:23, Daniel Migault  wrote:
>> >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron <
>> logana...@gmail.com> wrote:
>> >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault 
>> wrote:
>> >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
>> >> >>
>> >> >>
>> >> >> Please note the comment about Section 3 suggests changing server
>> behavior from SHOULD NOT to a MUST NOT.
>> >> >>
>> >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker <
>> nore...@ietf.org> wrote:
>> >> >> >
>> >> >> > Reviewer: Daniel Migault
>> >> >> > Review result: Ready with Nits
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> >
>> >> >> > I reviewed this document as part of the IoT Directorate's ongoing
>> effort to
>> >> >> > review all IETF documents being processed by the IESG.  These
>> comments were
>> >> >> > written primarily for the benefit of the Security Area
>> Directors.  Document
>> >> >> > authors, document editors, and WG chairs should treat these
>> comments just like
>> >> >> > any other IETF Last Call comments.
>> >> >> >
>> >> >> > Review Results: Ready with Nits
>> >> >> >
>> >> >> > Please find my comments below.
>> >> >> >
>> >> >> > Yours,
>> >> >> > Daniel
>> >> >> >
>> >> >> >
>> >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>> >> >> >  draft-ietf-tls-md5-sha1-deprecate-04
>> >> >> > [...]
>> >> >> >
>> >> >> > 1.  Introduction
>> >> >> >
>> >> >> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>> >> >> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>> >> >> >   insecure, subject to collision attacks [Wang].  In 2011,
>> [RFC6151]
>> >> >> >   detailed the security considerations, including collision
>> attacks for
>> >> >> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
>> >> >> >   [NISTSP800-131A-R2] and disallowed its use for digital
>> signatures at
>> >> >> >   the end of 2013, based on both the Wang, et. al, attack and the
>> >> >> >   potential for brute-force attack.  In 2016, researchers from
>> INRIA
>> >> >> >   identified a new class of transcript collision attacks on TLS
>> (and
>> >> >> >   other protocols) that rely on efficient collision-finding
>> algorithms
>> >> >> >   on the underlying hash constructions [Transcript-Collision].
>> >> >> >   Further, in 2017, researchers from Google and CWI Amsterdam
>> >> >> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
>> >> >> >   This document updates [RFC5246] and [RFC7525] in such a way
>> that MD5
>> >> >> >   and SHA-1 MUST NOT be used for digital signatures.  However,
>> this
>> >> >> >   document does not deprecate SHA-1 in HMAC for record protection.
>> >> >> >
>> >> >> > 
>> >> >> > RFC6194 may be mentioned as a reference for
>> >> >> > not deprecating HMAC-SHA-1 as well as an
>> >> >> > additional reference to

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

Hi Sean,

Thanks for the follow-up. I refreshed my memory as much as I could.  Please
see my responses in line.

Yours,
Daniel

On Tue, May 4, 2021 at 1:44 PM Sean Turner  wrote:

> Hopefully, I haven’t added too much time to the process but I stuck my
> beak in to see if I could propose some text to move this along. Apologies
> in advance: this is a long email. Once we settle on the text, I can submit
> PRs.
>
> spt
>
> > On Sep 14, 2020, at 11:11, Daniel Migault  wrote:
> >
> >  Hi Nick,
> >
> > Thanks for the response and I apologize for my delayed response. However
> I still have two major concerns regarding the current proposed text:
> >
> > Mentioning keyless as the only solution complementary to DC still seems
> to me technically inaccurate. With KeylessSSL, the key server  receives a
> hash based on randoms and ECDH parameters. The hash used in TLS 1.3 is
> different than in TLS 1.2 - when hashes are involved in the signature
> scheme - so Keyless would not work in this case - at least as far as I
> understand - and significant changes are need to make it work in TLS 1.3.
> > It seems to me technically more accurate to mention the effort performed
> on TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context.
> On the other hand, not mentioning it seems to me misleading. I also think
> it is misleading to not mention an effort that addresses the signing oracle
> security vulnerabilities associated to keylessSSL, leading to the
> impression that such attacks are inherent to the key server architecture -
> with a dedicated section 7.6. I understand, though, that
> draft-mglt-lurk-tls13 is not a commercial product and still an ongoing
> effort.
> > So far - unless I am missing them - I have not seen any technical
> justification for not mentioning that justify the single mention of
> keylessSSL and temptative of (non technical) procedural explanations do not
> seem valid ( see in line ).
>
> This is addressed later in the email.
>
> > Another concern I have - at least my understanding of it - is that DC is
> subject to downgrade attacks. Typically the TLS operator chooses the
> signature used by the DC to authenticate the server and this signature
> scheme can be weaker than the signature scheme provided by the CA. This
> prevents a content owner to enforce a (strong) level of authentication and
> - in the future - the use of deprecated/weak signature schemes. The threat
> model here is on the content owner perspective to ensure its website is
> strongly authenticated. The fact that the client can remove weak signature
> schemes does not seem sufficient as nothing seems to force the client to
> only use strong authentication with SignatureSchemeList potentially
> appearing in clear. The threat model you seem to refer to is the client to
> choose a strong authentication, but I think that is a bit different.
>
> This is addressed later in the email.
>
> > Please see my additional comments inline.
> >
> > Yours,
> > Daniel
> >
> >
> > On Wed, Aug 19, 2020 at 10:31 PM Nick Sullivan  40cloudflare@dmarc.ietf.org> wrote:
> > Daniel,
> >
> > Thank you for your thorough review. We've attempted to address these
> comments in the latest version on Github and are preparing to submit a -10.
> Answers inline below for these comments.
> >
> > Hannes, thank you for your comment as well.
> >
> > The changes are tracked here:
> > https://github.com/tlswg/tls-subcerts/pull/80
> >
> > On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
> > Hi,
> >
> > The draft has a number of nits and errors. Among others:
> >
> > The related work section mentions KEYLESS and subcert being
> complementary that is KEYLESS can perform the operations associated to the
> DC and/or those associated to the cert key. I do not think that is correct.
> KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK
> extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead.
> As LURK was mentioned during the adoption period and until version 05 that
> should not cause any issues.
> >
> > Technologies only available for TLS 1.2 may be mentioned in the related
> work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to
> KEYLESS as it addresses the security concerns of KEYLESS.
> >
> > There are other places where the extensions is mentioned together with
> TLS 1.2 that needs to be updated.
> >
> > I also think that test vectors would be good as well as a link to a
> formal verification publication (if available).
> >
> > Please see all my comme

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

Thanks for the update and the followup. To me the only remaining point I am
not sure has been fully addressed is the clarification of 5246, but
otherwise we agree on the content to be written. Please find my comments
inline.

Yours,
Daniel

On Tue, May 4, 2021 at 1:23 PM Sean Turner  wrote:

> Daniel,
>
> Thanks for your (and the WG’s) patience on this. Responses in line.
>
> spt
>
> > On Apr 9, 2021, at 14:54, Sean Turner  wrote:
> >> On Jan 22, 2021, at 08:23, Daniel Migault  wrote:
> >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron <
> logana...@gmail.com> wrote:
> >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault 
> wrote:
> >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
> >> >>
> >> >>
> >> >> Please note the comment about Section 3 suggests changing server
> behavior from SHOULD NOT to a MUST NOT.
> >> >>
> >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker <
> nore...@ietf.org> wrote:
> >> >> >
> >> >> > Reviewer: Daniel Migault
> >> >> > Review result: Ready with Nits
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> >
> >> >> > I reviewed this document as part of the IoT Directorate's ongoing
> effort to
> >> >> > review all IETF documents being processed by the IESG.  These
> comments were
> >> >> > written primarily for the benefit of the Security Area Directors.
> Document
> >> >> > authors, document editors, and WG chairs should treat these
> comments just like
> >> >> > any other IETF Last Call comments.
> >> >> >
> >> >> > Review Results: Ready with Nits
> >> >> >
> >> >> > Please find my comments below.
> >> >> >
> >> >> > Yours,
> >> >> > Daniel
> >> >> >
> >> >> >
> >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >> >> >  draft-ietf-tls-md5-sha1-deprecate-04
> >> >> > [...]
> >> >> >
> >> >> > 1.  Introduction
> >> >> >
> >> >> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >> >> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >> >> >   insecure, subject to collision attacks [Wang].  In 2011,
> [RFC6151]
> >> >> >   detailed the security considerations, including collision
> attacks for
> >> >> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
> >> >> >   [NISTSP800-131A-R2] and disallowed its use for digital
> signatures at
> >> >> >   the end of 2013, based on both the Wang, et. al, attack and the
> >> >> >   potential for brute-force attack.  In 2016, researchers from
> INRIA
> >> >> >   identified a new class of transcript collision attacks on TLS
> (and
> >> >> >   other protocols) that rely on efficient collision-finding
> algorithms
> >> >> >   on the underlying hash constructions [Transcript-Collision].
> >> >> >   Further, in 2017, researchers from Google and CWI Amsterdam
> >> >> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >> >> >   This document updates [RFC5246] and [RFC7525] in such a way that
> MD5
> >> >> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
> >> >> >   document does not deprecate SHA-1 in HMAC for record protection.
> >> >> >
> >> >> > 
> >> >> > RFC6194 may be mentioned as a reference for
> >> >> > not deprecating HMAC-SHA-1 as well as an
> >> >> > additional reference to [NISTSP800-131A-R2].
> >> >>
> >> >> Are asking for something like this:
> >> >>
> >> >> OLD:
> >> >>
> >> >>   In 2011, [RFC6151] detailed the security considerations,
> >> >>   including collision attacks for MD5.
> >> >>
> >> >> NEW:
> >> >>
> >> >>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
> >> >>   including collision attacks for MD5 and SHA-1, respectively.
> >> >>
> >> >> > Reading the text the situation of HMAC with
> >> >>

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

[Daniel Migault]

Hi,

It is unclear to me if the current version is expected to address the
comments received during the WGLCs or if further versions are expected.
Just to clarify the current version does not address my comments concerning
the related work section [1].

Yours,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/tls/B7qc2sPH_d9Tfr-W7vnf24jiGds/

On Sun, Jan 31, 2021 at 11:59 PM Sean Turner  wrote:

> Do you think this would be clearer:
>
>   The maximum validity period is set to 7 days unless
>   an application profile standard specifies a shorter
>   period.
>
> spt
>
> > On Jan 25, 2021, at 11:14, Russ Housley  wrote:
> >
> > I have reviewed the recent update, and I notice one inconsistency.
> >
> > Section 2 says:
> >
> >   In the absence of an application profile standard
> >   specifying otherwise, the maximum validity period is set to 7 days.
> >
> > Section 4.1.3 says:
> >
> >   1.  Validate that DelegatedCredential.cred.valid_time is no more than
> >   7 days.
> >
> > I think that Section 2 is trying to say that an application profile can
> make it even shorter than 7 days, but on my first reading I got the
> opposite.
> >
> > Russ
> >
> >
> >> On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote:
> >>
> >>
> >> 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   : Delegated Credentials for TLS
> >>   Authors : Richard Barnes
> >> Subodh Iyengar
> >> Nick Sullivan
> >> Eric Rescorla
> >>  Filename: draft-ietf-tls-subcerts-10.txt
> >>  Pages   : 19
> >>  Date: 2021-01-24
> >>
> >> Abstract:
> >>  The organizational separation between the operator of a TLS endpoint
> >>  and the certification authority can create limitations.  For example,
> >>  the lifetime of certificates, how they may be used, and the
> >>  algorithms they support are ultimately determined by the
> >>  certification authority.  This document describes a mechanism by
> >>  which operators may delegate their own credentials for use in TLS,
> >>  without breaking compatibility with peers that do not support this
> >>  specification.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-10
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> ___
> >> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron 
wrote:

> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault 
> wrote:
> >
> > Hi,
> >
> > I apology for responding so late - I missed the thread. I want this
> document to be moved forward but so far I do not have the impression my
> concerns have been addressed. I suppose that results from my lake of
> responsiveness and I apology. Please find my response inline and let me
> know what can be achieved reasonably.
> >
> > Yours,
> > Daniel
> >
> >
> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
> >>
> >>
> >> Please note the comment about Section 3 suggests changing server
> behavior from SHOULD NOT to a MUST NOT.
> >>
> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker <
> nore...@ietf.org> wrote:
> >> >
> >> > Reviewer: Daniel Migault
> >> > Review result: Ready with Nits
> >> >
> >> > Hi,
> >> >
> >> >
> >> > I reviewed this document as part of the IoT Directorate's ongoing
> effort to
> >> > review all IETF documents being processed by the IESG.  These
> comments were
> >> > written primarily for the benefit of the Security Area Directors.
> Document
> >> > authors, document editors, and WG chairs should treat these comments
> just like
> >> > any other IETF Last Call comments.
> >> >
> >> > Review Results: Ready with Nits
> >> >
> >> > Please find my comments below.
> >> >
> >> > Yours,
> >> > Daniel
> >> >
> >> >
> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >> >  draft-ietf-tls-md5-sha1-deprecate-04
> >> > [...]
> >> >
> >> > 1.  Introduction
> >> >
> >> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >> >   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
> >> >   detailed the security considerations, including collision attacks
> for
> >> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
> >> >   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
> >> >   the end of 2013, based on both the Wang, et. al, attack and the
> >> >   potential for brute-force attack.  In 2016, researchers from INRIA
> >> >   identified a new class of transcript collision attacks on TLS (and
> >> >   other protocols) that rely on efficient collision-finding algorithms
> >> >   on the underlying hash constructions [Transcript-Collision].
> >> >   Further, in 2017, researchers from Google and CWI Amsterdam
> >> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >> >   This document updates [RFC5246] and [RFC7525] in such a way that MD5
> >> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
> >> >   document does not deprecate SHA-1 in HMAC for record protection.
> >> >
> >> > 
> >> > RFC6194 may be mentioned as a reference for
> >> > not deprecating HMAC-SHA-1 as well as an
> >> > additional reference to [NISTSP800-131A-R2].
> >>
> >> Are asking for something like this:
> >>
> >> OLD:
> >>
> >>   In 2011, [RFC6151] detailed the security considerations,
> >>   including collision attacks for MD5.
> >>
> >> NEW:
> >>
> >>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
> >>   including collision attacks for MD5 and SHA-1, respectively.
> >>
> >> > Reading the text the situation of HMAC with
> >> > MD5 is unclear. Since we specify that SHA-1
> >> > is not deprecated for HMAC we may specify
> >> > the status for HMAC with MD5. Given RFC6151 I
> >> > hope the reason is that MD5 and HMAC-MD5 has
> >> > already been deprecated but I have not found
> >> > this. Maybe that would worth mentioning it
> >> > is deprecated already.
> >> >
> >> > 
> >>
> >> Are you asking for something like this:
> >>
> >> OLD:
> >>
> >>   However, this document does not deprecate SHA-1 in HMAC
> >>   for record protection.
> >>
> >>   However, this  document does not deprecate MD-5 or SHA-1 HMAC
> >>   for recor

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

I apology for responding so late - I missed the thread. I want this
document to be moved forward but so far I do not have the impression my
concerns have been addressed. I suppose that results from my lake of
responsiveness and I apology. Please find my response inline and let me
know what can be achieved reasonably.

Yours,
Daniel


On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:

>
> Please note the comment about Section 3 suggests changing server behavior
> from SHOULD NOT to a MUST NOT.
>
> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Daniel Migault
> > Review result: Ready with Nits
> >
> > Hi,
> >
> >
> > I reviewed this document as part of the IoT Directorate's ongoing effort
> to
> > review all IETF documents being processed by the IESG.  These comments
> were
> > written primarily for the benefit of the Security Area Directors.
> Document
> > authors, document editors, and WG chairs should treat these comments
> just like
> > any other IETF Last Call comments.
> >
> > Review Results: Ready with Nits
> >
> > Please find my comments below.
> >
> > Yours,
> > Daniel
> >
> >
> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >  draft-ietf-tls-md5-sha1-deprecate-04
> > [...]
> >
> > 1.  Introduction
> >
> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
> >   detailed the security considerations, including collision attacks for
> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
> >   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
> >   the end of 2013, based on both the Wang, et. al, attack and the
> >   potential for brute-force attack.  In 2016, researchers from INRIA
> >   identified a new class of transcript collision attacks on TLS (and
> >   other protocols) that rely on efficient collision-finding algorithms
> >   on the underlying hash constructions [Transcript-Collision].
> >   Further, in 2017, researchers from Google and CWI Amsterdam
> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >   This document updates [RFC5246] and [RFC7525] in such a way that MD5
> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
> >   document does not deprecate SHA-1 in HMAC for record protection.
> >
> > 
> > RFC6194 may be mentioned as a reference for
> > not deprecating HMAC-SHA-1 as well as an
> > additional reference to [NISTSP800-131A-R2].
>
> Are asking for something like this:
>
> OLD:
>
>   In 2011, [RFC6151] detailed the security considerations,
>   including collision attacks for MD5.
>
> NEW:
>
>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
>   including collision attacks for MD5 and SHA-1, respectively.
>
> > Reading the text the situation of HMAC with
> > MD5 is unclear. Since we specify that SHA-1
> > is not deprecated for HMAC we may specify
> > the status for HMAC with MD5. Given RFC6151 I
> > hope the reason is that MD5 and HMAC-MD5 has
> > already been deprecated but I have not found
> > this. Maybe that would worth mentioning it
> > is deprecated already.
> >
> > 
>
> Are you asking for something like this:
>
> OLD:
>
>   However, this document does not deprecate SHA-1 in HMAC
>   for record protection.
>
>   However, this  document does not deprecate MD-5 or SHA-1 HMAC
>   for record protection.


maybe we could add these are still considered as secured at the time of
writing.  It is also tempting to add that given we deprecate sha1 and md5
in the signature, it is tempting to suggest to use unless necessary
hmac-sha256.  I have commented the PR12


> <
> > [...]
> >
> > 2.  Signature Algorithms
> >
> >   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
> >   extension.  If a client does not send a signature_algorithms
> >   extension, then the server MUST abort the handshake and send a
> >   handshake_failure alert, except when digital signatures are not used
> >   (for example, when using PSK ciphers).
> >
> > 
> > It seems to me that the server behavior might
> > be defined as well. In our case this could be
> > something around the lines the server MUST
> > ignore MD5 and SHA1 values in the signature
> > algorithm extension.
> >
> > 
>
> 

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

First I deeply apologize for taking so long to respond, I just realized now
these responses.

I do not believe a review of IoT protocol is needed, I am more thinking
that TLS document should serve as a base guidance for TLS. Specific needs
for IoT are addressed based on the generic guidances. In some cases
specific extensions, cipher suites - not referenced by IANA as recommended
- will be needed to address specific corner cases.

Yours,
Daniel

On Tue, Oct 27, 2020 at 11:32 PM Sean Turner  wrote:

>
>
> > On Oct 27, 2020, at 10:32, Daniel Migault  wrote:
> >
> > To address the comment below, keeping weak security is likely to weaken
> current and future IoT communications, so I do not think there is room for
> compromise with performance. Of course this is in a context of TLS.  I
> expect protocol to leverage from TLS security, so the impact should be
> rather negligible.
> >
> > """
> > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a
> review of impacted IoT protocols if those algorithms are deprecated.
> > """
>
> In terms of process, are you suggesting "a review of impacted IoT
> protocols if those algorithms are deprecated” MUST be completed prior to
> advancing this document to the IESG?
>
> spt
>
> > Yours,
> > Daniel
> >
> >
> > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker <
> nore...@ietf.org> wrote:
> > Reviewer: Daniel Migault
> > Review result: Ready with Nits
> >
> > Hi,
> >
> >
> > I reviewed this document as part of the IoT Directorate's ongoing effort
> to
> > review all IETF documents being processed by the IESG.  These comments
> were
> > written primarily for the benefit of the Security Area Directors.
> Document
> > authors, document editors, and WG chairs should treat these comments
> just like
> > any other IETF Last Call comments.
> >
> > Review Results: Ready with Nits
> >
> > Please find my comments below.
> >
> > Yours,
> > Daniel
> >
> >
> >  Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >   draft-ietf-tls-md5-sha1-deprecate-04
> > [...]
> >
> > 1.  Introduction
> >
> >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
> >detailed the security considerations, including collision attacks for
> >MD5.  NIST formally deprecated use of SHA-1 in 2011
> >[NISTSP800-131A-R2] and disallowed its use for digital signatures at
> >the end of 2013, based on both the Wang, et. al, attack and the
> >potential for brute-force attack.  In 2016, researchers from INRIA
> >identified a new class of transcript collision attacks on TLS (and
> >other protocols) that rely on efficient collision-finding algorithms
> >on the underlying hash constructions [Transcript-Collision].
> >Further, in 2017, researchers from Google and CWI Amsterdam
> >[SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >This document updates [RFC5246] and [RFC7525] in such a way that MD5
> >and SHA-1 MUST NOT be used for digital signatures.  However, this
> >document does not deprecate SHA-1 in HMAC for record protection.
> >
> > 
> > RFC6194 may be mentioned as a reference for
> > not deprecating HMAC-SHA-1 as well as an
> > additional reference to [NISTSP800-131A-R2].
> >
> > Reading the text the situation of HMAC with
> > MD5 is unclear. Since we specify that SHA-1
> > is not deprecated for HMAC we may specify
> > the status for HMAC with MD5. Given RFC6151 I
> > hope the reason is that MD5 and HMAC-MD5 has
> > already been deprecated but I have not found
> > this. Maybe that would worth mentioning it
> > is deprecated already.
> >
> > 
> >
> > [...]
> >
> > 2.  Signature Algorithms
> >
> >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
> >extension.  If a client does not send a signature_algorithms
> >extension, then the server MUST abort the handshake and send a
> >handshake_failure alert, except when digital signatures are not used
> >(for example, when using PSK ciphers).
> >
> > 
> > It seems to me that the server behavior might
> > be defined as well. In our case this could be
> > something around the lines the server MUST
> > ignore MD5 and SHA1 values in the signature
> &

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

To address the comment below, keeping weak security is likely to weaken
current and future IoT communications, so I do not think there is room for
compromise with performance. Of course this is in a context of TLS.  I
expect protocol to leverage from TLS security, so the impact should be
rather negligible.

"""
As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a
review of impacted IoT protocols if those algorithms are deprecated.
"""
Yours,
Daniel


On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Daniel Migault
> Review result: Ready with Nits
>
> Hi,
>
>
> I reviewed this document as part of the IoT Directorate's ongoing effort to
> review all IETF documents being processed by the IESG.  These comments were
> written primarily for the benefit of the Security Area Directors.  Document
> authors, document editors, and WG chairs should treat these comments just
> like
> any other IETF Last Call comments.
>
> Review Results: Ready with Nits
>
> Please find my comments below.
>
> Yours,
> Daniel
>
>
>  Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>   draft-ietf-tls-md5-sha1-deprecate-04
> [...]
>
> 1.  Introduction
>
>The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>detailed the security considerations, including collision attacks for
>MD5.  NIST formally deprecated use of SHA-1 in 2011
>[NISTSP800-131A-R2] and disallowed its use for digital signatures at
>the end of 2013, based on both the Wang, et. al, attack and the
>potential for brute-force attack.  In 2016, researchers from INRIA
>identified a new class of transcript collision attacks on TLS (and
>other protocols) that rely on efficient collision-finding algorithms
>on the underlying hash constructions [Transcript-Collision].
>Further, in 2017, researchers from Google and CWI Amsterdam
>[SHA-1-Collision] proved SHA-1 collision attacks were practical.
>This document updates [RFC5246] and [RFC7525] in such a way that MD5
>and SHA-1 MUST NOT be used for digital signatures.  However, this
>document does not deprecate SHA-1 in HMAC for record protection.
>
> 
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2].
>
> Reading the text the situation of HMAC with
> MD5 is unclear. Since we specify that SHA-1
> is not deprecated for HMAC we may specify
> the status for HMAC with MD5. Given RFC6151 I
> hope the reason is that MD5 and HMAC-MD5 has
> already been deprecated but I have not found
> this. Maybe that would worth mentioning it
> is deprecated already.
>
> 
>
> [...]
>
> 2.  Signature Algorithms
>
>Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>extension.  If a client does not send a signature_algorithms
>extension, then the server MUST abort the handshake and send a
>handshake_failure alert, except when digital signatures are not used
>(for example, when using PSK ciphers).
>
> 
> It seems to me that the server behavior might
> be defined as well. In our case this could be
> something around the lines the server MUST
> ignore MD5 and SHA1 values in the signature
> algorithm extension.
>
> 
>
> 3.  Certificate Request
>
>Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
>messages.
>
> 
> It seems to me that the same level of
> authentication should be provided for both
> peers and that server MUST NOT  include MD5
> or SHA-1.
>
> A SHOULD NOT status might be welcome for a
> smooth transition. At that time, collision
> for MD5 and SHA1 are known for years. It is likely
> that software that still need MD5 or SHA1 are
> likely to never upgrade, so I doubt a smooth
> path worth being taken.
> 
>
> 4.  Server Key Exchange
>
>Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
>If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
>message it MUST abort the connection with the illegal_parameter
>alert.
>
> 
> As per section 2, the client has clearly
> indicated it does not support signature with
> MD5/SHA1, so Server Key Exchange should not
> end up with signature with SHA1/MD5.
>
> """
> If the client has offered the "signature_algorithms" extension, the
>signature algorithm and hash algorithm MUST be a pair listed in that
>extension.
> ""

[TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault via Datatracker]

Reviewer: Daniel Migault
Review result: Ready with Nits

Hi,


I reviewed this document as part of the IoT Directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Security Area Directors.  Document
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.  

Review Results: Ready with Nits

Please find my comments below.

Yours,
Daniel


 Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
  draft-ietf-tls-md5-sha1-deprecate-04
[...]

1.  Introduction

   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
   detailed the security considerations, including collision attacks for
   MD5.  NIST formally deprecated use of SHA-1 in 2011
   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
   the end of 2013, based on both the Wang, et. al, attack and the
   potential for brute-force attack.  In 2016, researchers from INRIA
   identified a new class of transcript collision attacks on TLS (and
   other protocols) that rely on efficient collision-finding algorithms
   on the underlying hash constructions [Transcript-Collision].
   Further, in 2017, researchers from Google and CWI Amsterdam
   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
   This document updates [RFC5246] and [RFC7525] in such a way that MD5
   and SHA-1 MUST NOT be used for digital signatures.  However, this
   document does not deprecate SHA-1 in HMAC for record protection.


RFC6194 may be mentioned as a reference for
not deprecating HMAC-SHA-1 as well as an
additional reference to [NISTSP800-131A-R2]. 

Reading the text the situation of HMAC with
MD5 is unclear. Since we specify that SHA-1
is not deprecated for HMAC we may specify
the status for HMAC with MD5. Given RFC6151 I
hope the reason is that MD5 and HMAC-MD5 has
already been deprecated but I have not found
this. Maybe that would worth mentioning it
is deprecated already.



[...]

2.  Signature Algorithms

   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
   extension.  If a client does not send a signature_algorithms
   extension, then the server MUST abort the handshake and send a
   handshake_failure alert, except when digital signatures are not used
   (for example, when using PSK ciphers).


It seems to me that the server behavior might
be defined as well. In our case this could be
something around the lines the server MUST
ignore MD5 and SHA1 values in the signature
algorithm extension. 



3.  Certificate Request

   Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
   messages.


It seems to me that the same level of
authentication should be provided for both
peers and that server MUST NOT  include MD5
or SHA-1.

A SHOULD NOT status might be welcome for a
smooth transition. At that time, collision
for MD5 and SHA1 are known for years. It is likely
that software that still need MD5 or SHA1 are
likely to never upgrade, so I doubt a smooth
path worth being taken. 


4.  Server Key Exchange

   Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
   If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
   message it MUST abort the connection with the illegal_parameter
   alert.


As per section 2, the client has clearly
indicated it does not support signature with
MD5/SHA1, so Server Key Exchange should not
end up with signature with SHA1/MD5. 

"""
If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension. 
"""

It also seems to me that the constraint of
including a MD5 and SHA-1 signature is
related to the Certificate. I suspect that
some clarification are needed here.  

Since the case where the extension becomes
mandatory, the quoted text above of RFC 5246
might be updated as well, though this does
not appear that necessary.



5.  Certificate Verify

   Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
   If a server receives a CertificateVerify message with MD5 or SHA-1 it
   MUST abort the connection with handshake_failure or
   insufficient_security alert.




6. Certificate 

Unless I am missing something, it seems to me
that signature may also be found in the
Certificate messages for the chain as well in
the restriction of the signature algorithm.
The end certificate is associated to the peer
while other certificate are related to a CA. 

It seems that client and server behavior may
be specified. The quoted text below may be
helpful to clarify. 

"""
 If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by 

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

Hi Ilari,

Thanks for the feed back. PLease see my comments inline.
Yours,
Daniel

On Wed, Sep 16, 2020 at 8:29 AM Ilari Liusvaara 
wrote:

> On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote:
> >  Hi Nick,
> >
> > Thanks for the response and I apologize for my delayed response. However
> I
> > still have two major concerns regarding the current proposed text:
> >
> > Mentioning keyless as the only solution complementary to DC still seems
> to
> > me technically inaccurate. With KeylessSSL, the key server  receives a
> hash
> > based on randoms and ECDH parameters. The hash used in TLS 1.3 is
> different
> > than in TLS 1.2 - when hashes are involved in the signature scheme - so
> > Keyless would not work in this case - at least as far as I understand -
> and
> > significant changes are need to make it work in TLS 1.3.
>
> The way I understand Keyless is as generic mechanism.



Well the text mentions a remote signing mechanism - I understand as a
generic mechanism - followed by a reference [KEYLESS]. That reference says:
"""
Our work focuses specifically on the TLS handshake
proxying system implemented by CloudFlare in their Keyless
SSL product
"""
So I am not convinced Keyless can be interpreted as a generic mechanism as
opposed to a specific commercial solution.

Note that I am not against KEYLESS being mentioned. I am just raising the
issue this is not the only mechanism. My request is that, to appear
generic multiple mechanisms could be mentioned [keyless,
draft-mglt-lurk-tls12, draft-mglt-lurk-tls13]. At least I do not see how
mentioning the other mechanisms would affect the genericity or the
understanding. Note also these mechanisms were mentioned in previous
versions of the draft.


The reason why the
> Keyless paper did not discuss TLS 1.3 was that TLS 1.3 was very early
> draft, and thus in significant flux, when the Keyless paper was published.
>
> Extending the signed-DH variant of Keyless to work with TLS 1.3 is
> straightforward task. And there are already production implementations.


 
I am not saying that is hard to extend Keyless to TLS 1.3 nor to the TLS
client side. I am just saying the reference does not seems to do what is
described in the section. If there are already production implementations
of Keyless with TLS 1.3 the ref might be updated I agree. I am happy to
know which reference you would have in mind.
Again I am not discussing whether Keyless should or should not be
mentioned. I am willing to have other efforts being mentioned.
  

> It seems to me technically more accurate to mention the effort performed
> on
> > TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context.
> On
> > the other hand, not mentioning it seems to me misleading. I also think it
> > is misleading to not mention an effort that addresses the signing oracle
> > security vulnerabilities associated to keylessSSL, leading to the
> > impression that such attacks are inherent to the key server architecture
> -
> > with a dedicated section 7.6. I understand, though,
> > that  draft-mglt-lurk-tls13 is not a commercial product and still an
> > ongoing effort.
> > So far - unless I am missing them - I have not seen any technical
> > justification for not mentioning that justify the single mention of
> > keylessSSL and temptative of (non technical) procedural explanations do
> not
> > seem valid ( see in line ).
>
> IIRC, some analysis of Keyless type scheme found some security issues.
> All but one was associated with RSA variant, and thus not a concern
> with using TLS 1.3. The remaining one involved interaction with gQUIC.
> AFAIK, the security issues with gQUIC that led to the problem have been
> fixed (and iQUIC never had the problem to begin with).
>
>

The vulnerability I had in mind was the signing oracle where Keyless signs
without context any provided hash value together with randoms.
It is difficult for me to comment on the TLS 1.3 version of Keyless since I
am not aware of it. The updated reference might help. That said, if the
hash is being sent to the key server, the situation is not improved in
terms of security over TLS 1.2. If the full handshake context is provided,
then this would represent a significant change compared to the version used
for TLS 1.2 - at least in term of performances.  I also imagine that
Ed25519 will take the full handshake.
Even if  the full handshake is provided, probably more thoughts are needed
to see if that is sufficiently secure for both the TLS client or TLS server
as well as how anti-replay protection is implemented.
So to sum up further analysis is needed to be able to claim that keyless in
TLS 1.3 does not have vulnerabilities and effectively represents an
improvement over Keyless with TLS 1.2

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

 Hi Nick,

Thanks for the response and I apologize for my delayed response. However I
still have two major concerns regarding the current proposed text:

Mentioning keyless as the only solution complementary to DC still seems to
me technically inaccurate. With KeylessSSL, the key server  receives a hash
based on randoms and ECDH parameters. The hash used in TLS 1.3 is different
than in TLS 1.2 - when hashes are involved in the signature scheme - so
Keyless would not work in this case - at least as far as I understand - and
significant changes are need to make it work in TLS 1.3.
It seems to me technically more accurate to mention the effort performed on
TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context. On
the other hand, not mentioning it seems to me misleading. I also think it
is misleading to not mention an effort that addresses the signing oracle
security vulnerabilities associated to keylessSSL, leading to the
impression that such attacks are inherent to the key server architecture -
with a dedicated section 7.6. I understand, though,
that  draft-mglt-lurk-tls13 is not a commercial product and still an
ongoing effort.
So far - unless I am missing them - I have not seen any technical
justification for not mentioning that justify the single mention of
keylessSSL and temptative of (non technical) procedural explanations do not
seem valid ( see in line ).

Another concern I have - at least my understanding of it - is that DC is
subject to downgrade attacks. Typically the TLS operator chooses the
signature used by the DC to authenticate the server and this signature
scheme can be weaker than the signature scheme provided by the CA. This
prevents a content owner to enforce a (strong) level of authentication and
- in the future - the use of deprecated/weak signature schemes. The threat
model here is on the content owner perspective to ensure its website is
strongly authenticated. The fact that the client can remove weak signature
schemes does not seem sufficient as nothing seems to force the client to
only use strong authentication with SignatureSchemeList potentially
appearing in clear. The threat model you seem to refer to is the client to
choose a strong authentication, but I think that is a bit different.

Please see my additional comments inline.

Yours,
Daniel


On Wed, Aug 19, 2020 at 10:31 PM Nick Sullivan  wrote:

> Daniel,
>
> Thank you for your thorough review. We've attempted to address these
> comments in the latest version on Github and are preparing to submit a -10.
> Answers inline below for these comments.
>
> Hannes, thank you for your comment as well.
>
> The changes are tracked here:
> https://github.com/tlswg/tls-subcerts/pull/80
>
> On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> The draft has a number of nits and errors. Among others:
>>
>> The related work section mentions KEYLESS and subcert being complementary
>> that is KEYLESS can perform the operations associated to the DC and/or
>> those associated to the cert key. I do not think that is correct. KEYLESS
>> does not support TLS 1.3 while DC only works with TLS 1.3. The LURK
>> extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead.
>> As LURK was mentioned during the adoption period and until version 05 that
>> should not cause any issues.
>>
>> Technologies only available for TLS 1.2 may be mentioned in the related
>> work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to
>> KEYLESS as it addresses the security concerns of KEYLESS.
>>
>> There are other places where the extensions is mentioned together with
>> TLS 1.2 that needs to be updated.
>>
>> I also think that test vectors would be good as well as a link to a
>> formal verification publication (if available).
>>
>> Please see all my comments inline, I hope they help.
>>
>> Yours,
>> Daniel
>>
>> 
>>
>>  Delegated Credentials for TLS
>>draft-ietf-tls-subcerts-09
>>
>> [...]
>>
>> 1.  Introduction
>>
>>Typically, a TLS server uses a certificate provided by some entity
>>other than the operator of the server (a "Certification Authority" or
>>CA) [RFC8446] [RFC5280].  This organizational separation makes the
>>TLS server operator dependent on the CA for some aspects of its
>>operations, for example:
>>
>>*  Whenever the server operator wants to deploy a new certificate, it
>>   has to interact with the CA...
>>
>>*  The server operator can only use TLS signature schemes for which
>>   the CA will issue credentials.
>>
>>These dependenci

Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis

[Daniel Migault]

I support adoption.

On Wed, Sep 2, 2020 at 9:32 PM Christopher Patton  wrote:

> I support adoption.
>
> On Wed, Sep 2, 2020 at 6:17 PM Richard Barnes  wrote:
>
>> I agree that this is a worthwhile effort for the WG.
>>
>> On Wed, Sep 2, 2020 at 16:05 Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Sep 2, 2020 at 12:52 PM David Schinazi 
>>> wrote:
>>>
>>>> I support adoption and am willing to help review.
>>>>
>>>> In case anyone else finds it helpful, here's a diff from RFC 8446:
>>>>
>>>> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8446=draft-rescorla-tls-rfc8446-bis-00
>>>>
>>>
>>> Thanks. I attempted to backport all the substantive changes made in RPC
>>> processing. However, there are a number of places (tables, line breaks,
>>> etc.) where the formatter behaved differently. In addition, some of the
>>> references are different because of differences between
>>> kramdown2629/xml2rfc's automatic reference processing and how the RPC does
>>> things. If you find changes you believe are material, please send PRs.
>>>
>>> -Ekr
>>>
>>> David
>>>>
>>>> On Wed, Sep 2, 2020 at 10:02 AM Ben Smyth 
>>>> wrote:
>>>>
>>>>> I support adoption and I am willing to help work on this. (Eric has
>>>>> already incorporated many of my suggestions, many thanks for that.)
>>>>>
>>>>>
>>>>> ___
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> ___
>>>
>>> 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
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

On Thu, Jul 2, 2020 at 10:21 AM Jonathan Hoyland 
wrote:

> Hi All,
>
> For those interested, I've been working on a formal analysis of DCs the
> results of which should appear online in the next few days.
> I'll post to the list when it's up.
>
> Great! Thanks.

> In summary I managed to prove a server only version of DCs secure (i.e.
> does not violate any of the properties in Appendix E.1) under the Dolev-Yao
> model without resumption, and work on a more general result is ongoing.
>
> Regards,
>
> Jonathan
>
> On Mon, 29 Jun 2020 at 16:59, Joseph Salowey  wrote:
>
>> This is the second working group last call for Delegated Credentials for
>> TLS.  The latest draft can be found here:
>> https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.  There have been
>> 2 revisions since the last review.  Draft 8 contains changes that were not
>> committed in time for draft 7 and draft 9 contains revisions from the
>> previous WGLC.  Links to the Diffs between the draft 9 and draft 7 can be
>> found at the end of this message.   Please focus your review on the changes
>> between draft 7 and draft 9.  Please send your comments to the list by July
>> 13, 2020.
>>
>> Thanks,
>>
>> Sean and Joe
>>
>> [Inline Diff]
>> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-tls-subcerts-09.txt=draft-ietf-tls-subcerts-07.txt
>> [Side-by-side Diff]
>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt=draft-ietf-tls-subcerts-07.txt
>>
>> ___
>> 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
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

Hi Joe,

Thanks for the feed back, please find my responses inline.

Yours,
Daniel


From: Joseph Salowey 
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault 
Cc: Salz, Rich ;  

Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

HI Daniel

Some comments inline below:

On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault 
mailto:daniel.miga...@ericsson.com>> wrote:
Hi,

The draft has a number of nits and errors. Among others:

The related work section mentions KEYLESS and subcert being complementary that 
is KEYLESS can perform the operations associated to the DC and/or those 
associated to the cert key. I do not think that is correct. KEYLESS does not 
support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 
1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned 
during the adoption period and until version 05 that should not cause any 
issues.

Technologies only available for TLS 1.2 may be mentioned in the related work 
section.  [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLESS as 
it addresses the security concerns of KEYLESS.


[Joe] KEYLESS is a deployed technology that is addressing some of the same use 
cases as Delegated credentials.  I'm not sure of the status of 
draft-mglt-lurk-tls13.



To respond to your question regarding the status of draft-mglt-lurk-tls13 it is 
a work in progress. That said, I am a bit upset by the comment, so let me 
clarify my comment just in case I mis-interpreted something or I am completely 
wrong.

Firstly, I tried to briefly describe the type of errors I think I noticed, so 
the co-authors do not need to parse all comments to get an idea of the types of 
errors. In this case, I had the impression that the subcert was initially 
intended to be an extension for TLS 1.2 and TLS 1.3, and the scope of TLS 1.2 
has been removed in version 02 while not all text have been updated 
accordingly. It is a bit more than nits but I do not see this as a major 
concern.

The related work section positions KEYLESS and subcert and think that is 
useful. My understanding is that KEYLESS only work for TLS 1.2 and for the 
server and subcert only works with TLS 1.3. When they shared a common TLS 
version, it was possible to use these 2 mechanisms together in a given TLS 
session.  Typically KEYLESS could host the private key of the DC or the X509 
certificate and proceed to the appropriated cryptographic operations. This is 
at least my understanding of the text below:

"""

   These two mechanisms can be complementary.  A server could use
   credentials for clients that support them, while using 
[KEYLESS<https://tools.ietf.org/html/draft-ietf-tls-subcerts-09#ref-KEYLESS>] to
   support legacy clients.  The private key for a delegated credential
   can be used in place of a certificate private key, so it is important
   that the Front-End and Back-End are parties that have a trusted
   relationship.

"""

Given that KEYLESS and DC work with different versions it seems hard to me that 
this could happen. I suspect there is an error and that KEYLESS is deployed or 
not seems to me a bit orthogonal to the fact that it does not achieve what is 
being written - or at least what I am understanding from the reading.

I believe the case of using KEYLESS-like technologies is important to be 
mentioned and I believe that draft-mglt-tls13 while being work in progress fits 
the use case while KEYLESS does not.
As mentioned in my text, I do not think adding LURK in the related work section 
represents a major update as the technology has been mentioned in the related 
work section during the adoption, and was there until version 05, and I do not 
recall this has raised any concerns at least on the mailing list. Digging on 
github I could only find [1], though I might have missed some discussions.

For the sake of clarity and trying to address potential - and purely 
speculative - questions that may lie behind the initial question:
* I think the related work section is useful as it clarifies concepts that had 
been confusing in the past. In addition, I have the impression that delegation 
may not be entirely deployed with DC and that complementary technology is 
needed - at least for the peer not supporting the extension.
* I am not asking that KEYLESS be removed even if - as I understand - KEYLESS 
only address TLS 1.2. I think that is clearly stated.
* I do not think the status of work in progress prevents soem work to be 
mentioned in a related work section. In some cases a draft status is sufficient 
for the IANA to assign code points.
* I also believe that [draft-mglt-lurk-tls12] should be mentioned as it 
addresses some security concerns among others the signing oracle. It seems 
there are some misunderstanding around this [1].

If there is anything you would like me to clarify, feel free to let  me know. I 
also believe that clarifications are p

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault]

Hi,

The draft has a number of nits and errors. Among others:

The related work section mentions KEYLESS and subcert being complementary that 
is KEYLESS can perform the operations associated to the DC and/or those 
associated to the cert key. I do not think that is correct. KEYLESS does not 
support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 
1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned 
during the adoption period and until version 05 that should not cause any 
issues.

Technologies only available for TLS 1.2 may be mentioned in the related work 
section.  [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLESS as 
it addresses the security concerns of KEYLESS.

There are other places where the extensions is mentioned together with TLS 1.2 
that needs to be updated.

I also think that test vectors would be good as well as a link to a formal 
verification publication (if available).

Please see all my comments inline, I hope they help.

Yours,
Daniel



 Delegated Credentials for TLS
   draft-ietf-tls-subcerts-09

[...]

1.  Introduction

   Typically, a TLS server uses a certificate provided by some entity
   other than the operator of the server (a "Certification Authority" or
   CA) [RFC8446] [RFC5280].  This organizational separation makes the
   TLS server operator dependent on the CA for some aspects of its
   operations, for example:

   *  Whenever the server operator wants to deploy a new certificate, it
  has to interact with the CA.

   *  The server operator can only use TLS signature schemes for which
  the CA will issue credentials.

   These dependencies cause problems in practice.  Server operators
   often deploy TLS termination services in locations such as remote
   data centers or Content Delivery Networks (CDNs) where it may be
   difficult to detect key compromises.  Short-lived certificates may be
   used to limit the exposure of keys in these cases.


I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA.

Typically server operators


   However, short-lived certificates need to be renewed more frequently
   than long-lived certificates.  If an external CA is unable to issue a
   certificate in time to replace a deployed certificate, the server
   would no longer be able to present a valid certificate to clients.
   With short-lived certificates, there is a smaller window of time to
   renew a certificates and therefore a higher risk that an outage at a
   CA will negatively affect the uptime of the service.

   To reduce the dependency on external CAs, this document proposes a
   limited delegation mechanism that allows a TLS peer to issue its own
   credentials within the scope of a certificate issued by an external
   CA.  These credentials only enable the recipient of the delegation to
   speak for names that the CA has authorized.  For clarity, we will
   refer to the certificate issued by the CA as a "certificate", or
   "delegation certificate", and the one issued by the operator as a
   "delegated credential" or "DC".


>From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator.



3.  Solution Overview

[...]

3.1.  Rationale

   Delegated credentials present a better alternative than other
   delegation mechanisms like proxy certificates [RFC3820] for several
   reasons:

   *  There is no change needed to certificate validation at the PKI
  layer.

   *  X.509 semantics are very rich.  This can cause unintended
  consequences if a service owner creates a proxy certificate where
  the properties differ from the leaf certificate.  For this reason,
  delegated credentials have very restricted semantics that should
  not conflict with X.509 semantics.

   *  Proxy certificates rely on the certificate path building process
  to establish a binding between the proxy certificate and the
  server certificate.  Since the certificate path building process
  is not cryptographically protected, it is possible that a proxy
  certificate could be bound to another certificate with the same
  public key, with different X.509 parameters.  Delegated
  credentials, which rely on a cryptographic binding between the
  entire certificate and the delegated credential, cannot.

   *  Each delegated credential is bound to a specific signature
  algorithm that may be used to sign the TLS handshake ([RFC8446]




Barnes, et al.  Expires 28 December 2020[Page 6]

Internet-DraftDelegated Credentials for TLSJune 2020


  section 4.2.3).  This prevents them from being used with other,
 

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

[Daniel Migault]

My personal position is YES - that draft-ietf-tls-ticket-requests must
address the ticket reuse use case. A non negligible number of deployments
will benefit from this feature deliberately provided by RFC8446.
Yours,
Daniel



On Wed, Mar 4, 2020 at 11:07 AM Sean Turner  wrote:

> one more time ...
>
> All,
>
> The purpose of this message is to help the chairs judge consensus on the
> way forward for draft-ietf-tls-ticketrequests. The issue at hand is whether
> the client-initiated ticket request mechanism [0] should be modified to add
> support for ticket reuse, see [1] lines 160-214. As we see it, the way
> forward involves either one draft or two. To that end, we would like your
> input (YES or NO) on the following question by 2359 UTC 18 March 2020:
>
>  Must the ticket reuse use case be addresses
>  in draft-ietf-tls-ticketrequests?
>
> Full disclosure: RFC 8446 recommends against ticket reuse to help protect
> clients from passive observers correlating connections [2]. The PR supports
> ticket reuse for use cases for a server-to-server connection that has fixed
> source addresses and no connection racing; if adopted the WG will need to
> ensure that the security considerations are properly documented.
>
> Note: There have been at least three threads on this draft [3][4][5].
> Please, let’s try to avoid re-litigating the points made therein.
>
> Joe & Sean
>
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
> [2] https://tools.ietf.org/html/rfc8446#appendix-C.4
> [3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
> [4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
> [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/
> _______
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] progressing draft-ietf-tls-ticket-request

[Daniel Migault]

The changes proposed by Viktor in [1] address my concern and I am happy
with those.

I am also fine to to have further considerations in another draft as the
current structure let this to be document be moved forward.

I think it is important we provide means to minimize the resource involved,
and this includes the possibility to re-use ticket.

I am wondering if more text should be provided for:
new_session = n > 1
resumption = m  > 1

Yours,
Daniel

[1]
https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18/commits/3dd8be998435fb54bbf78369449099aca217347f

On Fri, Feb 28, 2020 at 11:24 AM Sean Turner  wrote:

> Hi!
>
> Based on Tommy Pauly’s suggestion [0], Joe and I believe that the best way
> for us to get to the place where we can declare rough consensus is to:
>
> * Consider the PR: [1].  This PR explains that when racing connections,
> the client will not necessarily know the number of tickets it will
> “consume”, so it should either have enough tickets for two subsequent
> handshake resumptions; or else use fewer tickets but potentially run out.
>
> * Consider adoption of an individual draft that describes an extension for
> hinting ticket reuse. This draft will also discuss the use cases around
> ticket reuse.
>
> Obviously, the rationale here is to progress this relatively simple draft,
> but allow the reuse discussion to continue. Again, we believe this allows
> us to declare rough consensus and avoid any deadlocks.
>
> Please let us know your thoughts on the PR, which (assuming the PR gets
> consensus) we plan to ask the authors to merge sometime around 6 March.
>
> Thanks,
> Joe and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/fOmUYve5DLomjx3-Df9xQy0bocg/
> [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Netdev 0x14 co-located with IETF107

[Daniel Migault]

Hi,

Just to follow-up with Netdev 0x14 co-located with the IETF. The schedule
has been announced <https://netdevconf.info/0x14/news.html?schedule-up>
[1], and the schedule <https://netdevconf.info/0x14/schedule.html> [2]
published. You can even filter according to your own interests (AI,
container, DDoS, driver, IoT, kubernetes, L2, L3, wireless, security, ...
and many more!).
Please have look and check here
<https://netdevconf.info/0x14/schedule.html >!

Check out registration information here
<https://netdevconf.info/0x14/registration.html> [3]

Yours,
Daniel

[1] https://netdevconf.info/0x14/news.html?schedule-up
[2] https://netdevconf.info/0x14/schedule.html
[3] https://netdevconf.info/0x14/registration.html


On Thu, Feb 13, 2020 at 8:35 PM Daniel Migault  wrote:

> Hi,
>
> This is just to let you know that Netdev 0x14 is back co-locating with
> IETF 107 in
> Vancouver. There are several security related talks that may be of
> interest.
>
> Note: Early bird registration is still open until 17th and that many other
> talks, sessions, workshops are also happening
> https://netdevconf.info/0x14/accepted-sessions.html
>
> 1) Performance study of kernel based TLS handshakes
>
> https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes
>
> 2) TLS performance characterization on modern x86 CPUs
>
> https://netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on-modern-x86-CPUs
>
> 3) Kernel based TLS Hardware offload
>
> https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementation-and-performance-gains
>
> 4) Addressing DDoS: Issuing SYN cookies in XDP
> https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP
>
> 5)  Security and Control of SR-IOV: What’s Our Responsibility if the
> Kernel is Bypassed?
>
> https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-IOV
>
> Yours,
> Daniel
>
>

-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Netdev 0x14 co-located with IETF107

[Daniel Migault]

Hi,

This is just to let you know that Netdev 0x14 is back co-locating with IETF
107 in
Vancouver. There are several security related talks that may be of interest..

Note: Early bird registration is still open until 17th and that many other
talks, sessions, workshops are also happening
https://netdevconf.info/0x14/accepted-sessions.html

1) Performance study of kernel based TLS handshakes
https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes

2) TLS performance characterization on modern x86 CPUs
https://netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on-modern-x86-CPUs

3) Kernel based TLS Hardware offload
https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementation-and-performance-gains

4) Addressing DDoS: Issuing SYN cookies in XDP
https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP

5)  Security and Control of SR-IOV: What’s Our Responsibility if the
Kernel is Bypassed?
https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-IOV

Yours,
Daniel
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

C.4 is clearly in a context where privacy is needed and by writing "SHOULD
NOT" TLS 1.3 takes instead the position there are some cases this is not
required.

"""

C.4 <https://tools.ietf.org/html/rfc8446#appendix-C.4>.  Client
Tracking Prevention

   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.
   Servers that issue tickets SHOULD offer at least as many tickets as
   the number of connections that a client might use; for example, a web
   browser using HTTP/1.1 [RFC7230
<https://tools.ietf.org/html/rfc7230>] might open six connections to a
   server.  Servers SHOULD issue new tickets with every connection.
   This ensures that clients are always able to use a new ticket when

   creating a new connection.
"""

On Mon, Feb 3, 2020 at 12:02 AM Eric Rescorla  wrote:

>
>
> On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre  wrote:
>
>> On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault > 40ericsson@dmarc.ietf.org> wrote:
>>
>>>
>>> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla  wrote:
>>>
>>>>
>>>>
>>>> 1. TLS 1.3 takes the position that reuse is bad and that position
>>>>is for good reasons, so we shouldn't undercut it in a new
>>>>extension.
>>>>
>>>>
>>
>>> . Appendix C.4 discourages tickets re-use when Client tracking is a
>>> concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes
>>> position this is not mandatory to renew tickets.
>>>
>>
> Somehow I didn't get Daniel's email, so responding to it here.
>
> C.4 is not conditional. It simply says "Clients SHOULD NOT reuse a ticket
> for multiple connections." My point is not that servers which do not renew
> are not compliant but rather that TLS 1.3 has taken the position that reuse
> is bad and therefore we should not add an extension to facilitate it.
>
> -Ekr
>
>
>> thanks,
>> Rob
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla  wrote:

> > On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
> >
> > > I would make several points here:
> > >
> > > 1. RFC 8446 explicitly discourages ticket reuse
> > >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
> > >should not be designing an extension to enable reuse. While it's
> > >potentially true that some applications do not benefit from
> > >non-reuse, creating a set of mechanisms around reuse risks those
> > >mechanisms being used in settings where reuse would be
> > >bad. Moreover. just because at present sending MTAs have weak
> > >privacy properties does not mean that we should bake in this
> > >situation permanently.
> >
> > Indeed I agree that ticket reuse is often undesirable, and expect that
> > it will be avoided in many cases.  So I am somewhat sympathetic to the
> > above as a starting point for the analysis.
> >
> > That said, I don't see that making reuse easier to negotiate is likely
> > to create significant opportunities for misuse.
>
> I'm actually making several points here:
>
> 1. TLS 1.3 takes the position that reuse is bad and that position
>is for good reasons, so we shouldn't undercut it in a new
>extension.
>
>
This statement seems wrong to me as TLS 1.3 does not provide such position.
Appendix C.4 discourages tickets re-use when Client tracking is a concern.
The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes position
this is not mandatory to renew tickets. As you mention, this position is
for good reasons, that is the consideration of other use cases than the web
browsing use case, and I also tend to agree with you we should not go
beyond what TLS 1.3 says - that is: not necessarily preventing ticket
re-use.

2. Creating a mechanism which encourages reuse increases the risk
>of reuse.
>
> You are responding to number (2), and I'll respond to that below,
> but I think the controlling point is actually (1). We shouldn't
> encourage reuse, period.
>
>
> > - Both the client *and* the server would need to opt-in to reuse.
> >
> >   * Even if the client asks for reuse, the server can invalidate
> > the old ticket (something it would need to be able to do
> > already to ensure non-reuse) and send a fresh one anyway.
> >
> > The client would have to replace the old with the new, since
> > it has to assume that the old is now likely invalid.
> >
> >   * Even if the server is willing to reuse, if the client asks
> > for a new ticket, the server has to assume the client has
> > a single-use cache, and should vend a new ticket.
> >
> >   so it takes bilateral coordination to arrive at reuse, and
> >   so accidental reuse in applications where it is inappropriate
> >   requires errors on both ends.
>
> The issue is less accidental reuse than joint misconfiguration (e.g.,
> bad defaults or bad advice in some Stack Overflow document).
>
>
>
> > > 2. The additional cost of multiple tickets seems extraordinarily
> > >small, so I am not at all persuaded that there is enough value in
> > >this use case to justify adding new protocol machinery, even
> > >ignoring point (1) above.
> >
> > Postfix has a shared cache (indexed by destination domain+mx host) for
> > multiple independent processes racing to use the cache to make remote
> > SMTP connections.
> >
> > Frequent writes to that cache create measurable overhead and still don't
> > prevent reuse.
>
> I'm sorry to say that I'm not that sympathetic to this position. I
> appreciate that it's inconvenient for Postfix to have frequent writes
> to the ticket cache, but what you propose to do is hoist this
> implementation idiosyncracy into the specification, and I don't think
> that that's a good tradeoff, both for complexity and because the
>
>
> > Transmission of unnecessary tickets is also wasteful of
> > network and other server resources.
>
> Well, my position here is that these tickets aren't unnecessary,
> because you should be using them, rather than violating the
> SHOULD in the 8446.
>
>
> > Erasing tickets on first use would be unwise, most existing servers will
> > not presently return a fresh ticket on resumption.
>
> This seems like a defect in those servers. However it can be handled
> by not erasing tickets until a new ticket is provided..
>
>
> >
> > > 3. If there *is* such value, then you can register your own extension
> > >which allows you to say the orthogonal thing, namely "don't send me
> > >any tickets at all if you are resuming". This would be more
> > >flexible in that you could then say "I would like 10 tickets, but
> > >only if you don't resume". Note that
> > >https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would
> > >allow you to do this efficiently.
> >
> > This is an interesting idea, but how would the two extensions interact?
>
> I would imagine the logic 

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

On Fri, Jan 31, 2020 at 9:14 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> I have no particular position about this draft but
> am curious about 2 things:
>
> #1 I don't get why it's not possible for postfix to
> determine the best way to manage tickets based on the
> destination port to which the ClientHello is sent. I
> totally get why that won't solve 100% of cases, but it
> would surely solve a huge percentage? Apologies if an
> answer was already posted as part of this v. long
> thread.
>
> #2 I don't get why Viktor's request for special handling
> for value 255 is a real problem for anyone. We have
> another thread today envisaging 2040 extensions flags,
> so I really have a hard time seeing what here justifies
> rejecting Viktor's argument. FWIW, this thread has not
> provided me with an obvious answer to #2 other than "not-
> invented-here." I'm not sure that declaring things in the
> rough where the only identifiable issue is NIH is the
> overall best outcome, longer term.
>

+ 1 I have not seen any technical answer either for not considering this
mechanism.

>
> Cheers,
> S.
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

On Fri, Jan 31, 2020 at 8:16 PM Rob Sayre  wrote:

> On Fri, Jan 31, 2020 at 5:11 PM Nico Williams 
> wrote:
>
>> On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote:
>> > On Fri, Jan 31, 2020 at 3:56 PM Nico Williams 
>> wrote:
>> > > Viktor's comment came before the end of WGLC, so the WG needs to
>> > > consider his comments,
>> >
>> > Yes.
>> >
>> > > and needs to reach consensus.
>> >
>> > No. This draft should move forward.
>>
>> WGLCs are not about finding and discussing spelling errors.  This is not
>> how the Standards-Track RFC publication process works.
>>
>
> If the scope of a document can be continually expanded during last call,
> it can be indefinitely postponed.
>
> It is unclear to me how this applies here. Could you be a bit more
explicit and state what, in your opinion, is continually expanding ?


> thanks,
> Rob
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

I support the proposal from Viktor. It is important to minimize the
involved resource and provide the client the ability to explicitly inform
the server its policy.

As explained above, this mechanism comes with no additional complexity and
address a full range of applications.

See below my comments inline:

Yours,
Daniel
On Tue, Jan 21, 2020 at 4:19 PM Eric Rescorla  wrote:

> I would make several points here:
>
> 1. RFC 8446 explicitly discourages ticket reuse
>(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
>should not be designing an extension to enable reuse. While it's
>potentially true that some applications do not benefit from
>non-reuse, creating a set of mechanisms around reuse risks those
>mechanisms being used in settings where reuse would be
>bad. Moreover. just because at present sending MTAs have weak
>privacy properties does not mean that we should bake in this
>situation permanently.
>

 Appendix C.4 discourages the re-use of tickets to avoid passive
monitoring. This recommendation only applies when privacy is involved, and
other use cases exist (VNF, IoT, MTA,...). This is not *potentially* true,
this is simply true. These use cases are considered by RFC8446 and thus
need be considered in this proposal.

>
> 2. The additional cost of multiple tickets seems extraordinarily
>small, so I am not at all persuaded that there is enough value in
>this use case to justify adding new protocol machinery, even
>ignoring point (1) above.
>
>
As explained before, the *machinery* is also largely exaggerated. Those for
who the cost of generating ticket is so extraordinarily small actually do
not need this extension and can generate an extra large number of tickets
(at no cost for them).  This statement seems to contradict at least the
Less ticket waste use case.  In addition, saving cost per connection scales
the number of connections which is not negligible.

3. If there *is* such value, then you can register your own extension
>which allows you to say the orthogonal thing, namely "don't send me
>any tickets at all if you are resuming". This would be more
>flexible in that you could then say "I would like 10 tickets, but
>only if you don't resume". Note that
>https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would
>allow you to do this efficiently.
>

It is unclear to me why, in this case, this would apply specially to
Viktor's proposal rather the counter proposal.


>
> Thus, I would prefer to advance this document as-is.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 20, 2020 at 9:54 PM Viktor Dukhovni 
> wrote:
>
>> On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote:
>>
>> > On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
>> > > Regarding Viktor's suggestion, I personally believe it would increase
>> the
>> > > complexity of the proposal, and I don't see use-cases compelling
>> enough
>> > > to warrant that complexity. I would rather keep this proposal as
>> simple as
>> > > possible.
>> >
>> > I see that I didn't respond to this.  I support David's view.
>> >
>> > Even the suggestion that clients that resume only request one assumes
>> > that clients only want one.  The client probably knows better than we
>> > do.  I would rather say nothing about the number and keep it simple. 0
>> > means 0, 1 means 1, N means N.
>>
>> The proposal has since been simplified. With 1 meaning 1, 2 meaning 2,
>> .  The only change is that 0 and 255 become special, with 255 meaning
>> definitely no tickets, and 0 meaning tickets only if the server sees a
>> need a replace the presented ticket.  Otherwise, the client has no way
>> to request refresh only if needed, and must ask for 1 just in case.
>>
>> Unnecessary tickets are a waste server and client resources and
>> bandwidth, and make external caches "hot" on clients that are perfectly
>> fine with a slowly changing series of multi-use tickets.
>>
>>
>> > FWIW, the cost of oversupply is often marginal, depending on
>> > circumstances.  In a client-speaks-first protocol with no client
>> > certificate, the server can occupy the first round trip with tickets
>> > and generally gain a performance advantage (as sending more will
>> > increase the congestion window in most cases).
>>
>> This is useless for clients with just a single mult-use slot in their
>> ticket cache.  Not everything is a web browser.
>>
>> > Otherwise, there are usually quiescent periods that can be exploited
>> > for sending tickets.  And tickets are small, and cheap to generate.
>> > With one exception: if you are relying on client authentication and
>> > packing that into tickets, I'm sorry.
>>
>> There's no need to exclude valid use-cases.  The refined proposal
>> is rather non-invasive, and handles this case cost-effectively
>> on clients that re-use tickets (and don't use early-data, ...).
>>
>> --
>> Viktor.
>>
>> ___
>> TLS mailing 

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi,

Being the last in the queue for a while I realized [1] presents a typo that
may prevent my response to be seen. If that were the case,  in order to
move the document forward, I am re-iterating:

I agree with the proposed text from David. This ends the MUST/SHOULD
discussion.

I also think we agreed the security consideration should provide some text
related to an amplification attack - when tickets are sent right after the
server Finished. If that helps I believe something around the the following
lines could be added:
"""

In some cases, a server may sent NewSessionTicket immediately upon
sending its Finished rather than waiting for the client Finished. An
attacker may take advantage of this behavior to create an
amplification attack proportional to the count value toward a target
by performing the key exchange over UDP with spoofed packets. The
limit on the number of NewSessionTicket messages sent in response to a
"ticket_request"  MUST be based on the applicability and the
amplification factor of such attack.

"""


The remaining discussion in the list seems related to Viktor proposal,
which I think would greatly improve the document.

Yours,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/tls/7Z0p1O2GzN52ztq46KdzpBVX0Hw


On Mon, Nov 25, 2019 at 12:04 PM Daniel Migault 
wrote:

>
>
> On Wed, Nov 20, 2019 at 10:20 PM David Schinazi 
> wrote:
>
>> Hi folks,
>>
>> I've chatted with Daniel and Chris offline, and I think there might
>> have been some miscommunication here. Please allow me to
>> rephrase what I think is going on, and please let me know if
>> this accurately represents your views.
>>
>> Daniel has a IoT use-case where due to memory constraints,
>> a client knows it can only handle a certain number of tickets,
>> and therefore Daniel was wondering if it would make sense to
>> make the requested number of tickets a required maximum
>> (as in a RFC 2119 MUST). However, server operators on this
>> thread have indicated that a MUST would get in the way of
>> implementing this, due to STEK rotation for example. Daniel
>> understands this, and is OK with the current mindset of the
>> document (which is only a hint, not a MUST). Additionally,
>> Daniel would prefer to see the document move forward.
>>
>> In order to try to address Daniel's comments, I attempted
>> to rephrase the normative section to suggest in more
>> stronger terms that servers really shouldn't be sending
>> more than the client's request, but keeping it a SHOULD.
>>
>> Here is the PR with the rephrase:
>> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10
>>
>> Here's a copy of the updated paragraph in the PR:
>>Clients can use TicketRequestContents.count to indicate the number of
>>tickets they would prefer to receive.  Servers SHOULD NOT send more
>>tickets than TicketRequestContents.count, as clients will most likely
>>discard any additional tickets.  Servers SHOULD additionally place a
>>limit on the number of tickets they are willing to send to save
>>resources.  Therefore, the number of NewSessionTicket messages sent
>>SHOULD be the minimum of the server's self-imposed limit and
>>TicketRequestContents.count.
>>
>> I apology for the late response. This addresses my MUST/SHOULD concern.
> Thanks David.
>
>
>> Regarding Viktor's suggestion, I personally believe it would increase the
>> complexity of the proposal, and I don't see use-cases compelling enough
>> to warrant that complexity. I would rather keep this proposal as simple as
>> possible.
>>
>
> I particularly like the proposal from Viktor and - at least as I see it -
> its associated simplicity. I believe it would be beneficial for the
> document to include it.
>
>
>>
>> Thanks,
>> David
>>
>>
>> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni 
>> wrote:
>>
>>> On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:
>>>
>>> > > Somebody should try to avoid ending up with N new tickets after
>>> > > every connection, but in could well be the client.
>>> >
>>> > Yes, I think that can and ought to be the client. The client is really
>>> the
>>> > only party that can know how many tickets have been "consumed" by
>>> potentially
>>> > failed attempts to connect that the server didn't see in time or got
>>> dropped.
>>>
>>> OK, in that case, the proposal, is that on resumption, if the proposed
>>> extension is *absent*, then the server should generally send just one
>>> rath

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

[Daniel Migault]

Hi Hannes,

My reading is that only compression/decompression applies to our case.
Fragmentation is optional and only concerns ipv6. I did not intent to make
the comment at an inappropriate time, but if so, please consider it when it
is appropriate.

Yours,
Daniel

On Thu, Nov 21, 2019 at 10:34 PM  wrote:

> Hi Daniel
>
>
>
> Although inappropriate to discuss at the time of the adoption call I
> wanted to point out that I looked at SCHC and was surprised to learn that
> it is more than a compression scheme but also includes a protocol for
> adding reliability. In my reading is essentially a replacement for 6lowpan.
> Unfortunately, this design decision does not make it a well suited
> mechanism for a generic compression mechanism. I am happy to get convinced
> otherwise.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS  *On Behalf Of *Daniel Migault
> *Sent:* Friday, November 22, 2019 10:20 AM
> *To:* Panos Kampanakis (pkampana) 
> *Cc:* TLS List 
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I clearly support the adoption of the work, but it seems important to
> ensure cTLS integrates or remains in line with the work on compression that
> has been accomplished at the IETF - SCHC defined in lpwan might be a
> starting point. It also seems important to me that cTLS defines mechanisms
> that could be reused as TLS 1.3 evolves.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) <
> pkamp...@cisco.com> wrote:
>
> +1, support adoption.
>
>
>
> *From:* TLS  *On Behalf Of *Dmitry Belyavsky
> *Sent:* Thursday, November 21, 2019 4:46 AM
> *To:* Sean Turner 
> *Cc:* TLS List 
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I support the adoption.
>
>
>
> On Thu, Nov 21, 2019 at 8:36 AM Sean Turner  wrote:
>
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
> and the LAKE BOF, which is now a chartered WG [3].  After some discussions,
> the ADs suggested [4] that the TLS WG consider whether this draft be
> adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile
> it, as appropriate. The authors revised cTLS and presented the revised
> draft at IETF 106 [5].  At IETF 106 there was support for adoption of cTLS
> as a WG item..  To confirm this on the list: if you believe that the TLS WG
> should not adopt this as a WG item, then please let the chairs know by
> posting a message to the TLS list by 2359 UTC 13 December 2019 (and say
> why).
>
> NOTE:
> : If the consensus is that this draft should be adopted as a WG item, then
> this will necessarily result in a WG rechartering discussions.  We would
> have gotten to this rechartering discussion anyway now that DTLS 1.3 is
> progressing out of the WG.
>
> Thanks,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [2] https://github.com/ekr/draft-rescorla-tls-ctls
> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
> [5]
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> ___
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi 
wrote:

> Hi folks,
>
> I've chatted with Daniel and Chris offline, and I think there might
> have been some miscommunication here. Please allow me to
> rephrase what I think is going on, and please let me know if
> this accurately represents your views.
>
> Daniel has a IoT use-case where due to memory constraints,
> a client knows it can only handle a certain number of tickets,
> and therefore Daniel was wondering if it would make sense to
> make the requested number of tickets a required maximum
> (as in a RFC 2119 MUST). However, server operators on this
> thread have indicated that a MUST would get in the way of
> implementing this, due to STEK rotation for example. Daniel
> understands this, and is OK with the current mindset of the
> document (which is only a hint, not a MUST). Additionally,
> Daniel would prefer to see the document move forward.
>
> In order to try to address Daniel's comments, I attempted
> to rephrase the normative section to suggest in more
> stronger terms that servers really shouldn't be sending
> more than the client's request, but keeping it a SHOULD.
>
> Here is the PR with the rephrase:
> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10
>
> Here's a copy of the updated paragraph in the PR:
>Clients can use TicketRequestContents.count to indicate the number of
>tickets they would prefer to receive.  Servers SHOULD NOT send more
>tickets than TicketRequestContents.count, as clients will most likely
>discard any additional tickets.  Servers SHOULD additionally place a
>limit on the number of tickets they are willing to send to save
>resources.  Therefore, the number of NewSessionTicket messages sent
>SHOULD be the minimum of the server's self-imposed limit and
>TicketRequestContents.count.
>
> I apology for the late response. This addresses my MUST/SHOULD concern.
Thanks David.


> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possible.
>

I particularly like the proposal from Viktor and - at least as I see it -
its associated simplicity. I believe it would be beneficial for the
document to include it.


>
> Thanks,
> David
>
>
> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni 
> wrote:
>
>> On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:
>>
>> > > Somebody should try to avoid ending up with N new tickets after
>> > > every connection, but in could well be the client.
>> >
>> > Yes, I think that can and ought to be the client. The client is really
>> the
>> > only party that can know how many tickets have been "consumed" by
>> potentially
>> > failed attempts to connect that the server didn't see in time or got
>> dropped.
>>
>> OK, in that case, the proposal, is that on resumption, if the proposed
>> extension is *absent*, then the server should generally send just one
>> rather
>> than any larger default.
>>
>> If the extension is present, it is up to the client to not blindly ask
>> for N
>> tickets each time, and generally ask for just one ticket on resumption,
>> once it
>> has sufficiently many tickets for the desired concurrency level, with each
>> parallel thread obtaining one replacement ticket its next connection.
>>
>> As discussed clients that prefer to reuse tickets, can ask for zero, and
>> get 1
>> only as-needed.  If the server supports reuse then all is well.
>>
>> If the server does not support and refuses reuse, then it will issue a new
>> ticket each time and may only accept it once, but the client may have a
>> single-slot cache.  If the client makes only one connection at a time,
>> this
>> also works, but if/when its handshakes with the server overlap (a narrow
>> window
>> of ~1RTT) and two connections attempt to resume with the same ticket, one
>> of
>> them will end up doing a full handshake, but only when the client and
>> server
>> applications have incompatible ticket reuse expectations.  Some friction
>> when the client and server are mismatched is not the end of the world.
>>
>> So on the whole I think the proposal still works with just a numeric
>> signal
>> (tweaked with 0xff == none and 0 == reuse), and the onus to "generally
>> send 1"
>> on resumption moved to the client (i.e. clients that don't solicit ticket
>> reuse
>> should request only 1 ticket once they have enough).
>>
>> --
>> Viktor.
>>
>> ___
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

[Daniel Migault]

I clearly support the adoption of the work, but it seems important to
ensure cTLS integrates or remains in line with the work on compression that
has been accomplished at the IETF - SCHC defined in lpwan might be a
starting point. It also seems important to me that cTLS defines mechanisms
that could be reused as TLS 1.3 evolves.

Yours,
Daniel

On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) <
pkamp...@cisco.com> wrote:

> +1, support adoption.
>
>
>
> *From:* TLS  *On Behalf Of * Dmitry Belyavsky
> *Sent:* Thursday, November 21, 2019 4:46 AM
> *To:* Sean Turner 
> *Cc:* TLS List 
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I support the adoption.
>
>
>
> On Thu, Nov 21, 2019 at 8:36 AM Sean Turner  wrote:
>
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
> and the LAKE BOF, which is now a chartered WG [3].  After some discussions,
> the ADs suggested [4] that the TLS WG consider whether this draft be
> adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile
> it, as appropriate. The authors revised cTLS and presented the revised
> draft at IETF 106 [5].  At IETF 106 there was support for adoption of cTLS
> as a WG item..  To confirm this on the list: if you believe that the TLS WG
> should not adopt this as a WG item, then please let the chairs know by
> posting a message to the TLS list by 2359 UTC 13 December 2019 (and say
> why).
>
> NOTE:
> : If the consensus is that this draft should be adopted as a WG item, then
> this will necessarily result in a WG rechartering discussions.  We would
> have gotten to this rechartering discussion anyway now that DTLS 1.3 is
> progressing out of the WG.
>
> Thanks,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [2] https://github.com/ekr/draft-rescorla-tls-ctls
> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
> [5]
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi,

Just to followup the discussion. I support Viktor,'s proposal as it
provides the ability to the client to specify what it wants rather than let
the server guess. What I am wondering is whether we are catching all
possible client "policies" or whether we should consider some additional
reserved values. Typically I do not see case where 200 tickets may be
requested, so we may have some place for reserved bits if needed.

I see my comment of how tickets are generated as complementary.

Yours,
Daniel



On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni 
wrote:

> On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:
>
> > > That also works, effectively treat 0xff as "-1", but all other
> > > values as non-negative, with 0 a request for re-use.  An isomorphic
> > > encoding, but without the "-1".
> >
> > [Jeremy had a more eloquent description of the vague sketch of an idea
> that I had in my head]
>
> Jeremy's "isomorphic" encoding works fine for me, and is likely less
> confusing.
> So, FWIW, it has my support.  Fleshing it out a bit more, I am proposing:
>
> - 0xff => send no tickets
>
> - 0x00 => reuse requested:
> + send no tickets if presented ticket is accepted and reusable
> + send one ticket if presented ticket is accepted, but is not
> reusable
>   (expired, or reuse is not allowed).
> + Also send one ticket if session could not be resumed and a full
>   handshake was performed.  Clients that reuse tickets don't need a
>   separate one for each session, so one per full handshake should
>   suffice.
>
> - 0x01-0xfe => client wants single-use tickets:
> + send up to that many tickets on full handshake,
> + however, generally send just 1 ticket on resumption, or when
>   replacing tickets during long-lived connections.  This helps to
>   reduce chronic ticket "oversupply".
>
> --
> Viktor.
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi Hubert,

I do not understand why tickets sent after PHA would be useless. It is also
unclear if not one solution means there are multiple good solutions - in
which case we could pick one - or that there is not one.  At least I would
envisioned something around the lines below.

For a given handshake as presented below, here are the NST with associated
number (n_0, ..., n_3) without any count value provided by the client. When
the client provides count I would expect these number to become (n'_0, ...,
n'_3) with n'_u = min(max(count- sum(n'_j, j
  ServerHello
  {Finished}
< [Application Data*]
<   NST (n_3)
  {Certificate*}
  {Finished}>
< NST (n_2)
  [Application Data]<---> [Application Data]
<-NST (n_1)
< CertificateRequest
  PHA response  ->
<-NST (n_0)
Yours,
Daniel


On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario  wrote:

> On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote:
> > Hi  Hubert,
> >
> > On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario  wrote:
> >
> >> On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
> >>> Hi Hubert,
>
> >>> I understand the reasons for SHOULD. At least this should be
> documented.
> >>> To
> >>> address your first point, of course the specification applies to the
> >>> server
> >>> that support the extension.
> >>
> >>> Your second concern is solved by limiting the
> >>> NTS of KEX.
> >>
> >> by "KEX" you mean handshake? but New Session Ticket messages are not
> sent
> >> during handshake, they are sent after handshake is finished
> >
> > yes. I would consider the NST as part of the handshake even for those
> sent
> > after the post-handshake authentication.
>
> that would make tickets useless for sessions that use PHA

> I agree better terms may be used.
> > The rekey aspect seems to me out of the handshake.
>
> rekey also don't impact the keys used for derivation of session ticket
> secrets...
>
> >> so how exactly you want to decide when server stopped sending NSTs after
> >> handshake finished?
> >>
> >
> > That the spec does not mention it does not mean this will not be defined.
> > Instead it means each implementer will have its own logic, definitions
> and
> > outputs. The same reasoning occurs to the complexity argument,not
> > specifying it does not reduce the complexity but let it to the
> > implementation with all unexpected corner cases.
>
> my point is that there is no good way to define it, if you want the count
> to be
> limited, you need provide a good way to do that
>
> I say that there isn't one, so defining it is futile
>
> >>> The third point is addressed by the minimum of the (count,
> >>> server_nbr). Note that I see count as a maximum. Overall I do not think
> >>> this would add much complexity.  The only complexity I see is when a
> >> server
> >>> sends NTS at different time in the KEX.
> >>
> >> again, and what if the server misbehaves?
> >>
> >
> > Again, it would be a bug but the current spec is very permissive, at
> least
> > in my opinion. I do not believe that not specifying the expected
> behaviors
> > will prevent misbehaviors to happen, it, instead simply legitimates them.
>
> a MUST requires strict definition, which we can't provide, a SHOULD is
> already
> in the draft
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi Hubert,

The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
hint will be interpreted in the future or depending on different
implementations.

I understand the reasons for SHOULD. At least this should be documented. To
address your first point, of course the specification applies to the server
that support the extension. Your second concern is solved by limiting the
NTS of KEX. The third point is addressed by the minimum of the (count,
server_nbr). Note that I see count as a maximum. Overall I do not think
this would add much complexity.  The only complexity I see is when a server
sends NTS at different time in the KEX.

Yours,
Daniel

On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario  wrote:

> On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:
> > Hi Chris,
> >
> > Thanks for the responses, please see my comments inline.
> >
> > Yours,
> > Daniel
> >
> > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
> >  wrote:
> > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> >> Hi,
> >>
> >> The current version is clearer than the previous one. However, as I
> >> understand the document, it still seems very asymmetric in the sense
> >> that it does not provide the client the ability to enforce a number. I
> >> believe more guidances/specifications are needed on how to interpret the
> >> count value. Interpretation is usually based on implicit assumptions of
> >> today's usages, and explicit signaling should, in my opinion,
> >> be preferred. In
> >> other words, I believe that long term interop will benefit from these
> >> additional specifications.
> >
> > I disagree with this assessment. The document is clear on this:
> >
> >A supporting server MAY use TicketRequestContents.count when
> >determining how many NewSessionTicket messages to send to a
> >requesting client, and SHOULD place a limit on the number of tickets
> >sent.  The number of NewSessionTicket messages sent SHOULD be the
> >minimum of the server's self-imposed limit and
> >TicketRequestContents.count.
> >
> > As has been stated before, the count is a *hint* to the server,
> > nothing more.
> >
> > That is my point, in my opinion a hint is under specified.
> >
> >> The problem stated in the introduction is that the server needs some
> >> information from the client in order to generate the appropriated number
> >> of tickets. In fact the client is likely to be the one that better knows
> >> the number of tickets to be generated, but the current text does not
> >> enable the client to enforce that number. Instead this is entirely left
> >> to the server.
> >
> > As above, I think you're misunderstanding the point of this
> > document. Ticket requests are hints to servers.
> >
> > On the contrary, I think I understood it correctly.
>
> we discussed it on the list, and the reason for such phrasing is
> multi-fold:
>  - the server doesn't have to implement this extension, as such, as per the
>basic TLS 1.3 RFC, it can send arbitrary number of extensions to client,
>so clients, to be RFC compliant, need to be able to process abritrary
> number
>tickets at arbitrary time after handshake finish
>  - making value in extension the exact number requested by client makes the
>implementation much more complex: is that number per connection? per
>session? what about post-handshake authentication? what about Session
> Ticket
>Encryption Key rollover? do we really want the client to abort the
> connection
>if server misbehaves and sends too many or too few tickets?
>  - while the client may think that it knows how many tickets it requires,
> that
>information may be out of date. If an HTTP server has been brought
> down,
> a
>connection to a given SNI may lead to a redirection page - in such cases
>there is no point in server sending tickets.
>
> so please, tell: what issue would be solved by making the count requested
> by
> client mandatory?
> Because I see it only increasing complexity of implementation for no
> benefit.
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Unless I am missing something, the text below seems to say otherwise.


Note: Although the resumption master secret depends on the client's
   second flight, a server which does not request client authentication
   MAY compute the remainder of the transcript independently and then
   send a NewSessionTicket immediately upon sending its Finished rather
   than waiting for the client Finished.  This might be appropriate in
   cases where the client is expected to open multiple TLS connections
   in parallel and would benefit from the reduced overhead of a
   resumption handshake, for example.



On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood 
wrote:

> On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote:
> > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> > > If tickets are sent right after the server Finished, before the the
> > > client Finished, these are only triggered by the clientHello - at
> least
> > > this is my understanding.
> >
> > Yes, that's correct. I thought your comment was about post-handshake
> > tickets (after confirmation from the client). Adding a note about this
> > pre-handshake completion is fine with me.
>
> Scratch that! I forgot we limited this extension to TLS 1.3, which
> prohibits sending NSTs until the client finished is received (
> https://tools.ietf.org/html/rfc8446#section-4.6.1).
>
> Best,
> Chris
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi,

If tickets are sent right after the server Finished, before the the client
Finished, these are only triggered by the clientHello - at least this is my
understanding.

Yours,
Daniel


On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood 
wrote:

>
>
> On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> > Hi Chris,
> >
> > Thanks for the responses, please see my comments inline.
> >
> > Yours,
> > Daniel
> >
> > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood 
> wrote:
> > > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> > >  > Hi,
> > >  >
> > >  > The current version is clearer than the previous one. However, as I
> > >  > understand the document, it still seems very asymmetric in the sense
> > >  > that it does not provide the client the ability to enforce a
> number. I
> > >  > believe more guidances/specifications are needed on how to
> interpret the
> > >  > count value. Interpretation is usually based on implicit
> assumptions of
> > >  > today's usages, and explicit signaling should, in my opinion, be
> preferred. In
> > >  > other words, I believe that long term interop will benefit from
> these
> > >  > additional specifications.
> > >
> > >  I disagree with this assessment. The document is clear on this:
> > >
> > >  A supporting server MAY use TicketRequestContents.count when
> > >  determining how many NewSessionTicket messages to send to a
> > >  requesting client, and SHOULD place a limit on the number of tickets
> > >  sent. The number of NewSessionTicket messages sent SHOULD be the
> > >  minimum of the server's self-imposed limit and
> > >  TicketRequestContents.count.
> > >
> > >  As has been stated before, the count is a *hint* to the server,
> nothing more.
> > >
> > That is my point, in my opinion a hint is under specified.
>
> I acknowledge your opinion, but as I think I've made clear, I don't agree.
> Sorry!
>
> > >  > The problem stated in the introduction is that the server needs some
> > >  > information from the client in order to generate the appropriated
> number
> > >  > of tickets. In fact the client is likely to be the one that better
> knows
> > >  > the number of tickets to be generated, but the current text does not
> > >  > enable the client to enforce that number. Instead this is entirely
> left
> > >  > to the server.
> > >
> > >  As above, I think you're misunderstanding the point of this document.
> Ticket requests are hints to servers.
> > >
> > On the contrary, I think I understood it correctly.
> > >  > Typically, if a device does not want to have more than one ticket.
> It
> > >  > should be able to indicate one and be sure it will only receive one
> > >  > ticket. The current specification does not prevent multiple tickets
> to
> > >  > be sent by the server.
> > >
> > >  Right, nor should it. Again, that's not a goal.
> > >
> > >  > The server can ignore the count value (MAY) even
> > >  > though it is known to support the extension. This means that a
> server
> > >  > could support the extension while still having a hard coded number
> of
> > >  > tickets. In addition, (SHOULD) let the server determining the
> number of
> > >  > tickets.
> > >  >
> > >  > Possible ways to address my concerns could be to limit the count
> value
> > >  > to the number of tickets generated during the KEX, and a server
> MUST NOT
> > >  > exceed the counter value. The text would need more guidance on how
> the
> > >  > server SHOULD behave when emitting at different time in the KEX -
> after
> > >  > the Finished message and after the post handshake authentication.
> > >
> > >  I don't think any text changes are needed to address these comments.
> > >
> > >  > The security consideration should in my opinion consider the fact
> that a
> > >  > client over UDP/DTLS may use the count value as an amplification
> factor
> > >  > to have the server flooding a target. The current text only seems to
> > >  > consider the computation aspect, not the bandwidth. If that cannot
> > >  > happen, it might be beneficial to add it. However, when a server
> sends
> > >  > tickets right after the Finished, it seems to me that can be used
> as an
> > >  > attack.
> > >
> > >  I'm not convinced this is useful to add. The target here is the
> client (attacker) that requested tickets.
> > The target is the spoofed source IP address.
>
> That would imply the attacker is able to complete a connection with this
> spoofed address, no?
>
> > >  Best,
> > >  Chris
> > >
> > >  ___
> > >  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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi Chris,

Thanks for the responses, please see my comments inline.

Yours,
Daniel

On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood 
wrote:

> On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> > Hi,
> >
> > The current version is clearer than the previous one. However, as I
> > understand the document, it still seems very asymmetric in the sense
> > that it does not provide the client the ability to enforce a number. I
> > believe more guidances/specifications are needed on how to interpret the
> > count value. Interpretation is usually based on implicit assumptions of
> > today's usages, and explicit signaling should, in my opinion, be
> preferred. In
> > other words, I believe that long term interop will benefit from these
> > additional specifications.
>
> I disagree with this assessment. The document is clear on this:
>
>A supporting server MAY use TicketRequestContents.count when
>determining how many NewSessionTicket messages to send to a
>requesting client, and SHOULD place a limit on the number of tickets
>sent.  The number of NewSessionTicket messages sent SHOULD be the
>minimum of the server's self-imposed limit and
>TicketRequestContents.count.
>
> As has been stated before, the count is a *hint* to the server, nothing
> more.
>
> That is my point, in my opinion a hint is under specified.


> > The problem stated in the introduction is that the server needs some
> > information from the client in order to generate the appropriated number
> > of tickets. In fact the client is likely to be the one that better knows
> > the number of tickets to be generated, but the current text does not
> > enable the client to enforce that number. Instead this is entirely left
> > to the server.
>
> As above, I think you're misunderstanding the point of this document.
> Ticket requests are hints to servers.
>
> On the contrary, I think I understood it correctly.


> > Typically, if a device does not want to have more than one ticket. It
> > should be able to indicate one and be sure it will only receive one
> > ticket. The current specification does not prevent multiple tickets to
> > be sent by the server.
>
> Right, nor should it. Again, that's not a goal.
>
> > The server can ignore the count value (MAY) even
> > though it is known to support the extension. This means that a server
> > could support the extension while still having a hard coded number of
> > tickets. In addition, (SHOULD) let the server determining the number of
> > tickets.
> >
> > Possible ways to address my concerns could be to limit the count value
> > to the number of tickets generated during the KEX, and a server MUST NOT
> > exceed the counter value. The text would need more guidance on how the
> > server SHOULD behave when emitting at different time in the KEX - after
> > the Finished message and after the post handshake authentication.
>
> I don't think any text changes are needed to address these comments.
>
> > The security consideration should in my opinion consider the fact that a
> > client over UDP/DTLS may use the count value as an amplification factor
> > to have the server flooding a target. The current text only seems to
> > consider the computation aspect, not the bandwidth. If that cannot
> > happen, it might be beneficial to add it. However, when a server sends
> > tickets right after the Finished, it seems to me that can be used as an
> > attack.
>
> I'm not convinced this is useful to add. The target here is the client
> (attacker) that requested tickets.
>

The target is the spoofed source IP address.

>

>  Best,
> Chris
>
> ___
> 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault]

Hi,

The current version is clearer than the previous one. However, as I
understand the document, it still seems very asymmetric in the sense
that it does not provide the client the ability to enforce a number. I
believe more guidances/specifications are needed on how to interpret the
count value. Interpretation is usually based on implicit assumptions of
today's usages, and explicit signaling should, in my opinion, be preferred.
In
other words, I believe that long term interop will benefit from these
additional specifications.

The problem stated in the introduction is that the server needs some
information from the client in order to generate the appropriated number
of tickets. In fact the client is likely to be the one that better knows
the number of tickets to be generated, but the current text does not
enable the client to enforce that number. Instead this is entirely left
to the server.

Typically, if a device does not want to have more than one ticket. It
should be able to indicate one and be sure it will only receive one
ticket. The current specification does not prevent multiple tickets to
be sent by the server. The server can ignore the count value (MAY) even
though it is known to support the extension. This means that a server
could support the extension while still having a hard coded number of
tickets. In addition, (SHOULD) let the server determining the number of
tickets.

Possible ways to address my concerns could be to limit the count value
to the number of tickets generated during the KEX, and a server MUST NOT
exceed the counter value. The text would need more guidance on how the
server SHOULD behave when emitting at different time in the KEX - after
the Finished message and after the post handshake authentication.

The security consideration should in my opinion consider the fact that a
client over UDP/DTLS may use the count value as an amplification factor
to have the server flooding a target. The current text only seems to
consider the computation aspect, not the bandwidth. If that cannot
happen, it might be beneficial to add it. However, when a server sends
tickets right after the Finished, it seems to me that can be used as an
attack.


Yours,
Daniel


On Tue, Nov 5, 2019 at 8:32 PM Martin Thomson  wrote:

> There was a lengthy discussion after the last time this was discussed.
> Can I request that an editor (or a chair) summarize that discussion and the
> resulting actions (if any)?  I was involved in that discussion, but I don't
> see any changes from that.  I'm totally OK with publication as-is, but I
> want to make sure that nothing got dropped.
>
> p.s., it might make sense to include some advisory text on prioritization
> of tickets vs. application data.  I can see a naive implementation of this
> seriously degrading application performance.  For instance, it doesn't take
> that many tickets to fill an early TCP congestion window.
>
> p.p.s., yes, if you keep issuing last calls, I will keep finding new
> things.
>
> On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote:
> > All,
> >
> > This is the working group last call for the "TLS Ticket Requests" draft
> > available at
> > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/.
> > Please review the document and send your comments to the list by 2359
> > UTC on 19 November 2019.
> >
> > Note the the GH repo for this draft can be found at:
> > https://github.com/tlswg/draft-ietf-tls-ticketrequest
> >
> > Thanks - J
> > ___
> > 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
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Daniel Migault]

If we suppose all tickets are sent by the server at once, I am wondering if
we have any case where the server will send more tickets that the number
provided by the hint.

Yours,
Daniel

On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario  wrote:

> On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote:
> > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario 
> wrote:
> > > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > > > > I understand the meaning of count is the higher limit of ticket
> and
> > > > > > the
> > > > > > server can provides any tickets between 0 and count. If that is
> > > > > > correct,
> > > > > > this could be clearly stated and indication to chose an
> appropriated
> > > > >
> > > > > value
> > > > >
> > > > > > for each cases may be provided.
> > > > > >
> > > > > > I would rather see the count value as a hard line from the server
> > > > > > with a
> > > > > > MUST NOT instead of a SHOULD NOT statement.
> > > > >
> > > > > see my previous comments: this ignores existence of post handshake
> > > > > authentication, ticket lifetimes and KeyUpdate
> > > >
> > > > I think we agree on the problem which is it is hard to have a
> specific
> > > > count as tickets may be sent at multiple time during the key
> exchange or
> > > > the later during the session. If the "SHOULD" is addressing this
> aspect
> > > > I
> > > > believe that more text is needed.. From my perspective, what I
> proposed
> > > > I
> > > > imagined that count was related to the maximum number of ticket
> provided
> > > > **each time the server is sending tickets**. The reason for having
> the
> > > > same
> > > > number is that the server does not know how the client will use these
> > > > tickets and the client does not know precisely when the server sends
> the
> > > > tickets. So at the end the number of tickets sent is likely to be
> > > > n*count
> > > > when n represents the number of times during the session tickets are
> > > > provided.
> > > >
> > > > My understanding of the SHOULD is that it makes legitimate for a
> server
> > > > to
> > > > ignore the count value provided by the client.
> > >
> > > yes, it looks like we are in agreement
> > >
> > > Sounds like something that should be spelled out explicitly in the
> draft.
> > > I.e. it should talk about groups of tickets, not tickets in connection,
> > > and it should definitely not specify the maximum number of tickets a
> > > server can send in a connection.
> >
> > Since it's meant as a hint, removing that clause (maximum number of
> tickets
> > a server can send in a connection) is reasonable, and sounds like it
> should
> > address the concerns here. (Assuming we also include text which says
> > servers should obviously place a cap on what they send, as they do
> today.)
> > Would you agree? I'm really trying to avoid this becoming overly complex,
> > as it's a very small feature.
>
> yes, having a "server SHOULD place a cap on the number of tickets it sends
> at
> once" with a note in security section that "not having such a limit may
> expose
> the server to DoS or amplification attacks" would be enough
>
> (note that without client certificate authentication, the server can use
> early
> exit from handshake method and thus send the extensions just as a result
> of a
> single ClientHello message)
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic___
> 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

Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

[Daniel Migault]

Hi,

For clarity to the WG I am summarizing the discussion of the "lesson learnt
from deprecation" thread.

There is in my opinion a consensus that the current text does not emphasize
enough that TLS 1.3 is the current version of TLS. There is also a
consensus that the current draft limits the wording in emphasizing that TLS
1.3 obsoletes TLS 1.2 and is the current version to consider.

The current texts that are subject to changes are the following:

TEXT A:

"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""

Proposed alternatives are:
a) remove the sentence
b) leave the sentence as it is
c) clarify the sentence for example with the following text:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""


TEXT B:

"""TLSv1.2 has been the recommended version for IETF protocols since 2008,
providing sufficient time to transition away from older versions."""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""The current recommended version for TLS is 1.3 and version 1.2 has been
recommended since 2008, providing sufficient time to transition away from
older versions."""

TEXT C:


"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2. At the time of writing this document
this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly
RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is
RECOMMENDED.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

My personal opinion is to have some text that reflects what we think.

Yours,
Daniel

On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk  wrote:

> On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 07/10/2019 18:29, Rob Sayre wrote:
> > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > > wrote:
> > >> we can't "UPDATE" an I-D.
> > >
> > > Not true. If you need to refer to something that's been IESG-approved
> but
> > > still in the RFC queue, you can leave a note for the RFC editor to
> update
> > > the reference to the eventual RFC number.
> >
> > That would be an UPDATE on the eventual RFC and not on the
> > I-D. And in this case, it'd IMO not be a good plan as a) the
>
> Recent IESGs have been taking the stance that it's weird to have "Updates:"
> to a document that's not yet an RFC, mostly preferring to pull the document
> in question back and get changed directly.  But ...
>
> > relevant WG didn't want that, b) the I-D in question is part
> > of a mega-cluster, so any dependency on it (as you suggest)
> > risks loadsa delay if the cluster doesn't get unstuck, which
> > can happen and c) our draft already stretches the header
>
>  given that C238 is unblocked, dependencies-wise, that seems
> questionable in this case.  (The whole set of documents does have to go
> through the xmlv2-->xmlv3 conversion, though.)
>
> > enough updating 85 RFCs - trying to add an I-D to that list
> > would break tools and cause much pointless process-angst.
> >
> > Mostly (a) is the reason to not do it though. If you want
> > to disagree with (a), then the right list for that would be
> > the rtcweb list I guess, even though the WG is now concluded
> > (which could, I guess, be (d);-)
> >
> > Overall, the cost isn't worth the benefit IMO.
>
> That's roughly where I'm landing, too, though as noted previously, it's
> largely up to the sponsoring AD.
>
> -Ben
>
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Daniel Migault]

Hi Hubert,

I agree.
Yours,
Daniel

On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario  wrote:

> On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario  wrote:
> > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > > I understand the meaning of count is the higher limit of ticket and
> the
> > > > server can provides any tickets between 0 and count. If that is
> correct,
> > > > this could be clearly stated and indication to chose an appropriated
> > >
> > > value
> > >
> > > > for each cases may be provided.
> > > >
> > > > I would rather see the count value as a hard line from the server
> with a
> > > > MUST NOT instead of a SHOULD NOT statement.
> > >
> > > see my previous comments: this ignores existence of post handshake
> > > authentication, ticket lifetimes and KeyUpdate
> >
> > I think we agree on the problem which is it is hard to have a specific
> > count as tickets may be sent at multiple time during the key exchange or
> > the later during the session. If the "SHOULD" is addressing this aspect I
> > believe that more text is needed.. From my perspective, what I proposed
> I
> > imagined that count was related to the maximum number of ticket provided
> > **each time the server is sending tickets**. The reason for having the
> same
> > number is that the server does not know how the client will use these
> > tickets and the client does not know precisely when the server sends the
> > tickets. So at the end the number of tickets sent is likely to be n*count
> > when n represents the number of times during the session tickets are
> > provided.
> >
> > My understanding of the SHOULD is that it makes legitimate for a server
> to
> > ignore the count value provided by the client.
>
> yes, it looks like we are in agreement
>
> Sounds like something that should be spelled out explicitly in the draft.
> I.e.
> it should talk about groups of tickets, not tickets in connection, and it
> should definitely not specify the maximum number of tickets a server can
> send
> in a connection.
>
> > > > The ability to request 255 tickets with one byte can be seen as an
> > > > amplification vector, especially when a server sends directly the
> > > > tickets
> > > > after its Finished message. I believe that additional text in the
> > >
> > > security
> > >
> > > > consideration could be added.
> > >
> > > true
> > >
> > > > Yours,
> > > > Daniel
> > > >
> > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood  >
> > >
> > > wrote:
> > > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> > > > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > > > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > > > > > > > ```
> > > > > > > > > > Servers MUST NOT send more than 255 tickets to clients.
> > > > > > > > > > ```
> > > > > > > > > >
> > > > > > > > > > per what? session? at a time? connection?
> > > > > > > > >
> > > > > > > > > This is all per session. We can state it explicitly in the
> > > > > > > > > next
> > > > >
> > > > > version.
> > > > >
> > > > > > > > so this count needs to be kept as part of session and impacts
> > > > >
> > > > > connections
> > > > >
> > > > > > > > that perform resumption?
> > > > > > >
> > > > > > > Sorry, I meant connection:
> > > > > > >"Clients may indicate to servers their desired number of
> > > > > > >tickets
> > > > >
> > > > > for *a
> > > > >
> > > > > > > single connection* via the following "ticket_request"
> extension"
> > > > > > >
> > > > > > > This is a simple hint for servers. Nothing more. No state
> needs to
> > >
> > > be
> > >
> > > > > stored
> > > > >
> > > > > > > past connection establishment.
> > > > > >
> > > >

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Daniel Migault]

On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario  wrote:

> On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > I understand the meaning of count is the higher limit of ticket and the
> > server can provides any tickets between 0 and count. If that is correct,
> > this could be clearly stated and indication to chose an appropriated
> value
> > for each cases may be provided.
> >
> > I would rather see the count value as a hard line from the server with a
> > MUST NOT instead of a SHOULD NOT statement.
>
> see my previous comments: this ignores existence of post handshake
> authentication, ticket lifetimes and KeyUpdate
>
>
I think we agree on the problem which is it is hard to have a specific
count as tickets may be sent at multiple time during the key exchange or
the later during the session. If the "SHOULD" is addressing this aspect I
believe that more text is needed.. From my perspective, what I proposed  I
imagined that count was related to the maximum number of ticket provided
**each time the server is sending tickets**. The reason for having the same
number is that the server does not know how the client will use these
tickets and the client does not know precisely when the server sends the
tickets. So at the end the number of tickets sent is likely to be n*count
when n represents the number of times during the session tickets are
provided.

My understanding of the SHOULD is that it makes legitimate for a server to
ignore the count value provided by the client.



> > The ability to request 255 tickets with one byte can be seen as an
> > amplification vector, especially when a server sends directly the tickets
> > after its Finished message. I believe that additional text in the
> security
> > consideration could be added.
>
> true
>
> > Yours,
> > Daniel
> >
> > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood 
> wrote:
> > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > > > > > ```
> > > > > > > > Servers MUST NOT send more than 255 tickets to clients.
> > > > > > > > ```
> > > > > > > >
> > > > > > > > per what? session? at a time? connection?
> > > > > > >
> > > > > > > This is all per session. We can state it explicitly in the next
> > >
> > > version.
> > >
> > > > > > so this count needs to be kept as part of session and impacts
> > >
> > > connections
> > >
> > > > > > that perform resumption?
> > > > >
> > > > > Sorry, I meant connection:
> > > > >"Clients may indicate to servers their desired number of tickets
> > >
> > > for *a
> > >
> > > > > single connection* via the following "ticket_request" extension"
> > > > >
> > > > > This is a simple hint for servers. Nothing more. No state needs to
> be
> > >
> > > stored
> > >
> > > > > past connection establishment.
> > > >
> > > > sounds good
> > > >
> > > > > > > > what's the expected behaviour with tickets and post-handshake
> > > > > > > > authentication? Are tickets sent after PHA also bound by this
> > >
> > > limit?
> > >
> > > > > > > As mentioned earlier, there is no effect, so we left it out.
> We're
> > >
> > > happy
> > >
> > > > > > > to
> > > > > > > accept text should you think it's needed.
> > > > > >
> > > > > > If the I-D states that servers should not send more tickets than
> the
> > > > > > client
> > > > > > asked for, and then send exactly that amount, then they won't be
> > >
> > > able to
> > >
> > > > > > send new tickets after PHA and remain compliant.
> > > > > >
> > > > > > Yes, it's completely up to the server to decide if to send
> tickets
> > >
> > > after
> > >
> > > > > > PHA or not, and I'm not suggesting that the client should request
> > > > > > for
> > > > > > tickets in one of its PHA messages, much less expect or require
> > >
> > > them, but
> > >
> > > 

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Daniel Migault]

Hi,

Please see my comments.

Yours,
Daniel
On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood  wrote:

> Hi Daniel,
>
> Please see inline below.
>
> On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> > Hi,
> >
> > Please find some comments on the draft.
> >
> > In the introduction, I believe both limitations may be merged into one
> > limitation which is the number of ticket is a server only decision. The
> > purpose of the extension is the client providing information so the
> > server can pick the appropriated number.
>
> I'd prefer we didn't merge them, though admittedly I don't feel strongly
> about this one way or the other.
>
> > I find "choose" and "hard-coded" a bit contradicting. If the server
> > uses a hard coded value for the number of tickets, then I would
> > understand the limitation as the server being unable to chose a value
> > per client or per connection. This seems to me an implementation
> > limitation and so maybe out of scope of the extension. If it is able to
> > choose that number, the limitation is that it is a server only
> > decision.
>
> Indeed. I think this is fairly clear from the draft. How would you suggest
> this be clarified?
>
The draft does not seem, in my opinion, to address the case when values are
hard coded. OK hardcoded is just there to expose it cannot chose the value.
It is fine.

>
> > I understand the meaning of count is the higher limit of ticket and the
> > server can provides any tickets between 0 and count. If that is
> > correct, this could be clearly stated and indication to chose an
> > appropriated value for each cases may be provided.
>
> The document states this:
>
>A supporting server MAY vend TicketRequestContents.count
>NewSessionTicket messages to a requesting client, and SHOULD NOT send
>more than TicketRequestContents.count NewSessionTicket messages to a
>requesting client.
>
> Is this not sufficient clear? If not, how can it be improved?
>
> > I would rather see the count value as a hard line from the server with
> > a MUST NOT instead of a SHOULD NOT statement.
>
> As this is merely a hint from the client, I don't think this is necessary.
>
> I believe we could be more specific than a hint, and a server supporting
the extension MUST NOT send more tickets then specified. This is what is
expected when count is set to 0.


> > My reading of 8446 is that NewSessionTicket messages can be sent at
> > multiple time during or after the handshake. If that is correct, it
> > seems to me quite complex to track the number of tickets that had been
> > sent. Typically, if I have to send them at different time how much
> > would I send at each flight. I would rather consider the min(count,
> > server_limit) as the number of tickets in any batch of NewSessionTicket
> > messages. We may also ask the client to only keep the latest batch of
> > tickets and delete the others previously sent tickets.
>
> This behavior is orthogonal to the intent of the hint. Imagine, for
> example, clients sent no hint and servers decided to do what you describe
> above. The same issues would still exist (tracking some count sent on the
> server, deciding which tickets to use on the client, etc.). Thus, I don't
> think this would add much value.
>
> If the servers receives a count value and sends tickets right after the
Finished message and after the post handshake authentication. How many
messages do you expect to be sent at each round?  I suggested to have count
at each round, as the server does not know how the client expects to use
these tickets. I have the impression the current text says count.

> >
> > The ability to request 255 tickets with one byte can be seen as an
> > amplification vector, especially when a server sends directly the
> > tickets after its Finished message. I believe that additional text in
> > the security consideration could be added.
>
> The text lists this:
>
>Servers SHOULD place a limit on the number of tickets they are willing
> to vend to clients.
>
> The draft mentions limitation of tickets to avoid computation of the
server, and I was reading the limit as to limit that computation, in which
case the limit addresses server's resource exhaustion. What I meant was the
use of the extension with a spoofed IP address.


> Though we can add a parenthetical to indicate that failure to do so may
> result in doing more work that intended.
>
> Thanks for the feedback!
>
> Best,
> Chris
>
> ___
> 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

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault]

Hi Kathleen,

On Tue, Oct 1, 2019 at 7:07 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
>
> On Tue, Oct 1, 2019 at 4:00 AM John Mattsson  40ericsson@dmarc.ietf.org> wrote:
>
>> Martin Thomson ; wrote:
>>
>> >When we release a new version of something, we are sending a message:
>> >
>> >1. new implementations and deployments MUST include support for newer
>> versions
>> >2. existing implementations and deployments SHOULD be updated to support
>> newer versions
>>
>> I agree very much with this summary and I would like to have it published
>> somewhere. Take for example RFC 8261. It was published almost 6 years after
>> RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and
>> not DTLS 1.2. I think this is one of the lessons IETF should learn from the
>> TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in the
>> future? For an external viewer it must look pretty strange that IETF in Nov
>> 2017 published an RFC relying on DTLS 1.0 and then 7 months later started
>> working on a draft forbidding its use
>>
>> I would like to see something like the following statements published:
>>
>> "New implementations and deployments MUST include support for TLS 1.3"
>>
> We have this already, I believe in new drafts.
>

The current wording does not, in my opinion, make the message clear in the
current draft. Maybe that is a perception of non native English speaker,
but there are probably three sentences that could in my opinion make the
message clearer.

>
>
>> "Existing implementations and deployments SHOULD be updated to support
>> TLS 1.3"
>> "Existing implementations and deployments SHALL support TLS 1.3 by
>> January 1, 2024"
>>
>
> Are you proposing a draft to state this?  If agreeable, this could be a
> quick draft and support for 1.3 is a reasonable request to align with
> requirements in industry.  I'm not sure if our statement will drive the
> date as much as NIST's, but it couldn't hurt and I would be surprised if
> there were any objections to this.
>
> I don't think anything other than an RFC is the right approach, unless
> there is an avenue I am not thinking about as having IETF consensus would
> be what you'd want for it.
>
>
>>
>> >> """The expectation is that TLSv1.2 will continue to be used for many
>> >> years alongside TLSv1.3."""
>> >
>> >Some people have that expectation, but I think that John is right to
>> challenge it.  >There remain reasons that people are sticking with 1.2 for
>> now, but those reasons >are mostly to do with allowing time to flush out
>> the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies.
>>
>> I agree with Martin, and irrespectively of whether it is true or not, I
>> do not see any need to have this sentence in an IETF draft.
>>
>
> As for this sentence, we'll see where the discussion settles out -
> removing or altering it.
>
> Best regards,
> Kathleen
>
>>
>> Cheers,
>> John
>>
>> -Original Message-
>> From: TLS  on behalf of Martin Thomson <
>> m...@lowentropy.net>
>> Date: Friday, 27 September 2019 at 02:03
>> To: "TLS@ietf.org" 
>> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
>>
>> So I agree with Kathleen's conclusion: not to change the goals of the
>> current document.  But there are changes that I think are necessary (and
>> thanks to Daniel and John for highlighting these).
>>
>> BTW, I've moved this to the TLS working group, because this is an
>> active topic there and I don't see anything in my email that SAAG needs to
>> concern itself with.
>>
>> On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
>> > My understanding of deprecating of TLS1.0 TLS 1.1 is that:
>> > a) new software do not use these versions
>> > b) existing software stop supporting these versions.
>>
>> That differs from my perspective.
>>
>> When we release a new version of something, we are sending a message:
>>
>> 1. new implementations and deployments MUST include support for newer
>> versions
>> 2. existing implementations and deployments SHOULD be updated to
>> support newer versions
>>
>> When we deprecate an old version of something, we are sending a
>> message:
>>
>> 3. only use this old version if you absolutely have to
>> 4. you are encou

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault]

Hi,

Maybe I am missing the point, but I do not see any reasons to not
explicitly recommend adoption of the latest version (i.e. TLS 1.3).

While the document deprecates old version, providing explicitly the status
of the non deprecated versions seems to me in scope of the document. As
such, clearly stating that TLS 1.3 or the latest version is expected seems
to me better, but I am happy to hear otherwise.

Removing the sentence that mentions TLS 1.2 and TLS 1.3 will coexist for a
long time, does not carry exactly the same message as explicitly
recommending the adoption of the latest version. I believe explicit
statement will help adoption of TLS 1.3.

To be clearer, I am providing the alternate text I had in mind. Of course
feel free to change the wording.

abstract:


OLD:

"""TLSv1.2 has been the recommended version for IETF protocols since 2008,
providing sufficient time to transition away from older versions."""

NEW:

"""The current recommended version for TLS is 1.3 and version 1.2 has been
recommended since 2008, providing sufficient time to transition away from
older versions."""

Introduction:

OLD:
"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""

NEW:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""


OLD:

"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

NEW:

"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2. At the time of writing this document
this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly
RECOMMENDED. If TLSv12.2 were not supported yet, adoption of TLSv1.3 is
RECOMMENDED.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

Yours,
Daniel

On Fri, Sep 27, 2019 at 4:46 AM Stephen Farrell 
wrote:

>
>
> On 27/09/2019 04:50, Martin Thomson wrote:
> > On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
>  """The expectation is that TLSv1.2 will continue to be used
>  for many years alongside TLSv1.3."""
> >>
> >> So is your proposed change to only remove that sentence?
> >
> > I just checked, and it seems like the only thing the document says
> > along these lines, so yeah.
>
> Grand so. Like I said I don't think it's a biggie so I've
> commented out that sentence in the GH version. [1]
>
>   [1]
>
> https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt
>
> BTW - for the chairs/AD - how are we doing on getting IETF LC under
> way? I realise the world won't end if this isn't super-fast but it's
> been 3 months since publication was requested which seems like a bit
> of a while.
>
> Cheers,
> S.
>
>
> >
> >> Personally, I'm not that fussed. Including or omitting that seems
> >> not a big deal to me. If the WG are however keen on such a change
> >> that's fine too. OTOH, we've already done a bunch of process-steps
> >> with this process-draft so I do wonder if that change really
> >> amounts to a worthwhile thing.
> >
> > I do.  Or I wouldn't have written the email.  Do you think that this
> > is a valuable statement?  I think that it says that the IETF lacks
> > confidence in the suitability of TLS 1.3 as a replacement for TLS
> > 1.2.
> >
> > If you want a smaller change, s/many years/some time/
> >
> ___
> 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

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault]

On Thu, Sep 26, 2019 at 8:03 PM Martin Thomson  wrote:

> So I agree with Kathleen's conclusion: not to change the goals of the
> current document.  But there are changes that I think are necessary (and
> thanks to Daniel and John for highlighting these).
>
> BTW, I've moved this to the TLS working group, because this is an active
> topic there and I don't see anything in my email that SAAG needs to concern
> itself with.
>

I think the reason John cc saag was that the request was more generic, that
is not only focused to TLS, but the current discussion is only TLS
focused.

>
> On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
> > My understanding of deprecating of TLS1.0 TLS 1.1 is that:
> > a) new software do not use these versions
> > b) existing software stop supporting these versions.
>
> That differs from my perspective.
>
> When we release a new version of something, we are sending a message:
>
> 1. new implementations and deployments MUST include support for newer
> versions
> 2. existing implementations and deployments SHOULD be updated to support
> newer versions
>
> When we deprecate an old version of something, we are sending a message:
>
> 3. only use this old version if you absolutely have to
> 4. you are encouraged to take active measures to remove the need to use
> the old version
> 5. you have our support if you decide not to support this old version
>
> I agree that how it should be. That said, if everyone were adopting the
newest version, we would probably do not even need to deprecate oldest
versions which would be phased out by themselves. Forum or standard bodies
are good to define a direction for adopting new version and deprecating old
versions. However, outside these groups, updating a new version is seen as
deployment/development cost and as such, old version tends to remain until
it is explicitly deprecated.


> Now, "support" from the IETF is about as meaningful as you think it is.
> And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ [RFC6919].


> In browser-land, we've decided to form a coalition when it comes to
> removing TLS 1.0/1.1.  3GPP have obviously got their own support group,
> which seems to be functioning effectively, which is great.
>
> > """The expectation is that TLSv1.2 will continue to be used for many
> > years alongside TLSv1.3."""
>
> Some people have that expectation, but I think that John is right to
> challenge it.  There remain reasons that people are sticking with 1.2 for
> now, but those reasons are mostly to do with allowing time to flush out the
> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.
>
> I believe that for a significant number of deployed software the reason to
stick to TLS 1.2 is that it works with TLS 1.2,  TLS 1.2 is not deprecated
and still supported (=not deprecated). However I would be happy to be
wrong.


> I would advocate for removing this statement and any residue of that
> sentiment from the draft.  It's speculation and, even if it were true, it
> conveys the wrong message.  The only message I would include is that one
> that is further down the document: "Any newer version of TLS is more secure
> than TLSv1.1."
>
> The opposite would be surprising, but I do understand your point. We could
remain focus on the deprecation, not the adoption of the newest version. My
motivation for explicitly push for TLS 1.3 was to remind your point 1) and
2). I think that would be useful to have these point in one way or another,
but that is only my opinion.

> ___
> 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

Re: [TLS] [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault]

Hi,

My understanding of deprecating of TLS1.0 TLS 1.1 is that:
a) new software do not use these versions
b) existing software stop supporting these versions.

I am not sure how likely a new software is to use TLS 1.0 or TLS 1.1 with
TLS 1.2 and TLS 1.3 being widely deployed. It seems also a current best
practise to take the latest version, and I am also not sure implementers
considering TLS 1.0 or TLS 1.1 would read this document. That said, it
might be good the current text provide a stronger recommendation to
consider the latest version of TLS which is 1.3.

For existing software, the reason to maintain these old versions is, as far
as I understand, usually that the other side is composed of a legacy
software. The deprecation on the server side, expects legacy devices to
become enable to serve their purpose and that hopefully someone will unplug
them. I believe that the document could emphasise a bit more and recommend
to move to include TLS 1.3. In addition, I am not sure how relevant it is,
but if a  software is not yet supporting TLS 1.2 - that is supporting TLS
1.0 and TLS 1.1 - I believe that we should explicitly recommend it to move
to TLS 1.3.

"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""


"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

The text above may be interpreted that TLS 1.2 is fine for a long time and
there is not need to upgrade to TLS 1.3. It may be helpful to clarify that
version compatibility should also consider TLS 1.3. I woudl suggest
something around the lines:

Even TLS 1.2 and TLS 1.3 are expected to co-exist for years, with the
deployment of TLS 1.3, it is RECOMMENDED to envisioned the phase out of TLS
1.2 and start deploying TLS 1.3. In addition, software that do not support
TLS 1.2 are RECOMMENDED to implement only TLS 1.3.

Another way around may be to add a section: "Use TLSv1.3".


Yours,
Daniel


On Thu, Sep 26, 2019 at 9:50 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
>
> Sent from my mobile device
>
> > On Sep 26, 2019, at 9:02 AM, Salz, Rich  wrote:
> >
> > These are excellent points.  Perhaps they can be squeezed into
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> ?  It's been waiting 90 days, a brief reset might not hurt :)
> >
> This would not be a brief reset and I’d prefer not to see them combined
> into the existing draft with WG agreement.
>
> With RFC7525, TLSv1.2 can be configured to be secure.  I see the points
> made, but don’t see the urgency as obsolete is different from depreciation.
>
> I think encouraging implementation of TLSv1.3 is good and important, but
> are there other ways besides deprecation?
>
> NIST has pushed back their date for US government organizations to have a
> plan to support TLSv1.3, what’s the driver to get ahead of that?
>
> A vulnerability would speed things up, but I do hope that does not happen..
>
> Best regards,
> Kathleen
>
> > On 9/26/19, 8:18 AM, "John Mattsson"  40ericsson@dmarc.ietf.org> wrote:
> >
> >Hi,
> >
> >Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1
> deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a
> myriad subtle ways and should according to me optimally have been
> deprecated years ago.
> >
> >3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that
> time not forbid use of TLS 1.1 as that would potentially break
> interoperability with some Rel-12 nodes (that had TLS 1.2 as should
> support). The lesson 3GPP learned from this was the need to as early as
> possible mandate support of new protocol versions. With TLS 1.3, 3GPP took
> action early and TLS 1.3 support was mandated for network nodes in Rel-15
> (2018) and for mobile phones in Rel-16 (2019).
> >
> >At some point in time we will want to deprecate TLS 1.2. To enable
> that, TLS 1.3 support should be mandated or encouraged as much as possible.
> I would like to avoid a situation where we want to deprecate TLS 1.2 but
> realize that it cannot be done because some implementations only support
> TLS 1.2. How can IETF enable smoother and faster deprecations in the
> future? The browser industry has a decent track record of algorithm
> deprecation and I hope to soon see the following warning in my browser:
> >
> >“TLS 1.2 is obsolete. Enable TLS 1.3 or later.”
> >
> >Other industries have less stellar track records of algorithm
> deprecation.
> >
> >How can IETF be more pro-active regarding deprecations in the future?
> In the best of words, nobody should be surprised when IETF deprecates a
> protocol version or algorithm. NIST and similar 

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault]

Thanks for raising this discussion John, we have been struggling with this
in curdle as well and ipsecme. This is also a topic that I believe would be
useful to improve the security.

One aspect is that some implementers go to the IANA pages and believe that
everything on the pages is acceptable. I believe that it would be worth
adding some status associated to the code points. Currently, in most cases
a reference is associated to the code point. In some cases, the reference
is the RFC or document creating that created the code point in other cases,
the reference could be the RFC that deprecates the code point. There is no
specific rules, and that is probably something that would worth being
clarified. That being clarified, I still believe that it could be useful to
have a some sort of indication like a column that indicates whether the
code point is deprecated or not. This may involve additional terminology
depending on the level of information needed.

Another aspect would be to have software automatically checking which are
the code points status. This would of course only solve one side of the
problem as a device may end up on becoming silent, but that is probably
what should occur to non maintained devices.

Yours,
Daniel



On Thu, Sep 26, 2019 at 8:18 AM John Mattsson  wrote:

> Hi,
>
> Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1
> deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a
> myriad subtle ways and should according to me optimally have been
> deprecated years ago.
>
> 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time
> not forbid use of TLS 1.1 as that would potentially break interoperability
> with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson
> 3GPP learned from this was the need to as early as possible mandate support
> of new protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3
> support was mandated for network nodes in Rel-15 (2018) and for mobile
> phones in Rel-16 (2019).
>
> At some point in time we will want to deprecate TLS 1.2. To enable that,
> TLS 1.3 support should be mandated or encouraged as much as possible. I
> would like to avoid a situation where we want to deprecate TLS 1.2 but
> realize that it cannot be done because some implementations only support
> TLS 1.2. How can IETF enable smoother and faster deprecations in the
> future? The browser industry has a decent track record of algorithm
> deprecation and I hope to soon see the following warning in my browser:
>
> “TLS 1.2 is obsolete. Enable TLS 1.3 or later.”
>
> Other industries have less stellar track records of algorithm deprecation..
>
> How can IETF be more pro-active regarding deprecations in the future? In
> the best of words, nobody should be surprised when IETF deprecates a
> protocol version or algorithm. NIST and similar organizations in other
> countries have the practice to long time in advance publish deadlines for
> security levels, algorithms, and protocol versions. Can the IETF do
> something similar, not just for TLS but in general? For TLS, there are
> several things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5,
> RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Static
> RSA, CBC, DH, NULL, etc.) should be deprecated in the future.
>
> Cheers,
> John
>
> ___
> 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

Re: [TLS] The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state "Call For Adoption By WG Issued"

[Daniel Migault]

I support the adoption of the draft.
Yours,
Daniel

On Wed, Jul 24, 2019 at 9:42 AM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state
> Call For Adoption By WG Issued (entered by Sean Turner)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-lvelvindron-tls-md5-sha1-deprecate/
>
> ___
> 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

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Daniel Migault]

On Tue, May 14, 2019 at 2:27 PM Hubert Kario  wrote:

> On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> > section 2:
> >
> > I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
> > one hand, deprecation should be smooth, but on the other hand I am
> reading
> > that rfc6194 and rfc6151 already started the deprecation. I would rather
> > favour MUST NOT.
> >
> > Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
> > receiver.
>
> that was the intention behind my suggestion for SHOULD NOT - i.e. the
> server
> MUST be able to handle ClientHello that does advertise them, but in
> practice
> ignore them based on required handling for SKE and CV
>
>
got it, then the text needs to be explicit in each case we should not hide
ourselves behind a vague SHOULD.


> > section 3:
> >
> > The title section maybe should be Certificate Request (without 's').
> > Similarly to the previous section I would suggest MUST NOT and specifying
> > how the client would behave upon receiving MD5 or SHA-1 as hash.
>
> same as above
>
> > section 6:
> >
> > The current rfc5246 rely on default sha-1 and md5. To ease
> interoperability
> > I am wondering if we strongly recommend to provide the signature
> algorithm
> > extension in addition to the default sha256.
>
> no, sha-1 is the default in case the extension is omitted, but then we
> also
> specify that if the extension is omitted now, the negotiation MUST fail
> the recommendation for sha256 is that it in practice has to be included in
> the
> extension as some servers use the extension to select server certificate,
> so
> omitting sha256 there will cause the connection to fail
>
> Works for me. I believe the reasoning worth being mentioning. In addition,
the section update of 5246 coudl also emphasis changes are not limited to
the NEW text.


> this is also partially the reason for a SHOULD NOT instead of MUST NOT for
> section 2 and 3 – I do not know how those servers handle interaction
> between
> SHA-1 missing in the extension and root CA (self-signed certificate) being
> signed by SHA-1
>
> I had the same question ;-) and of course not the response.  I believe
that we should clarify this and document the choice for MUST/SHOULD.

> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic___
> 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

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Daniel Migault]

Hi,

Please find some comments.

Yours,
Daniel

Introduction

I would suggest a reference to rfc6194 for sha1 digest as well as for
hmac-sha1.

I believe more text in the introduction may be needed to expose how the
document impacts TLS 1.2.

Typically, the impacted structure is HashAlgorithm, This structure is used
by SignatureAndHashAlgorithm which defines the Signature Algorithms
extension and is included in messages such as CertificateRequest  In
addition a number of messages rely on this extension (, ServerKeyExchange,
CertificateVerify) and they will be impacted by the current document.

Updating the HashAlgorithm registry was caught in the previous version by
updating the enum. While this is not the standard procedure to deprecate a
registry entry, I believe the intention was there. I would rather suggest
to do that in the IANA section..

section 2:

I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
one hand, deprecation should be smooth, but on the other hand I am reading
that rfc6194 and rfc6151 already started the deprecation. I would rather
favour MUST NOT.

Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
receiver.

section 3:

The title section maybe should be Certificate Request (without 's').
Similarly to the previous section I would suggest MUST NOT and specifying
how the client would behave upon receiving MD5 or SHA-1 as hash.

I believe SHA-1 has been dropped in section 4 and 5.

section 6:

The current rfc5246 rely on default sha-1 and md5. To ease interoperability
I am wondering if we strongly recommend to provide the signature algorithm
extension in addition to the default sha256.

section 7:

The new text is missing a capital letter: s/severs/Servers.

Unless i am missing something, I would limit the update to the scope of the
draft and leave the sentence discussing the group unchanged. .

In the following paragraph and s/MUST not/MUST NOT/.

I believe the IANA section is missing:

TLS HashAlgorithm should have the values

1 md5 Y [RFCTBD]
2 sha1 Y [RFCTBD]


Yours,
Daniel


On Tue, May 14, 2019 at 7:25 AM Hubert Kario  wrote:

> On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> > Latest draft is here:
> > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt
>
> why did you drop SHA-1 from Section 4 and 5?
>
> the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly
> that
> ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by
> it
>
> SKE and CV don't use HMAC
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic___
> 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

Re: [TLS] RFC8446 Fig3

[Daniel Migault]

thanks, I just submitted the erratum.
Yours,
Daniel

On Thu, May 2, 2019 at 8:48 PM Martin Thomson  wrote:

> That's right.  You might open an editorial erratum, which I would suggest
> be held for document update.
>
> Note that there is no promise that the list of extensions is complete, as
> this doesn't show the supported_versions or signature_schemes extension
> either, but the omission is probably not great in this case, since the PSK
> modes  are highly relevant.
>
> On Fri, May 3, 2019, at 10:30, Daniel Migault wrote:
> > Hi,
> >
> > This might have already been mentioned on the list, but unless I
> > misinterpreter something it seems to me that the second handshake of
> > figure 3 is missing psk_key_exchange_modes extension.
> >
> > Yours,
> > Daniel
> >
> >  Figure 3 shows a pair of handshakes in which the first handshake
> >  establishes a PSK and the second handshake uses it:
> >  Client Server
> >  Initial Handshake:
> >  ClientHello
> >  + key_share >
> >  ServerHello
> >  + key_share
> >  {EncryptedExtensions}
> >  {CertificateRequest*}
> >  {Certificate*}
> >  {CertificateVerify*}
> >  {Finished}
> >  < [Application Data*]
> >  {Certificate*}
> >  {CertificateVerify*}
> >  {Finished} >
> >  < [NewSessionTicket]
> >  [Application Data] <---> [Application Data]
> >  Subsequent Handshake:
> >  ClientHello
> >  + key_share*
> >  + pre_shared_key >
> >  ServerHello
> >  + pre_shared_key
> >  + key_share*
> >  {EncryptedExtensions}
> >  {Finished}
> >  < [Application Data*]
> >  {Finished} >
> >  [Application Data] <---> [Application Data]
> >  Figure 3: Message Flow for Resumption and PSK
> >
> > ___
> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] RFC8446 Fig3

[Daniel Migault]

Hi,

This might have already been mentioned on the list, but unless I
misinterpreter something it seems to me that the second handshake of figure
3 is missing psk_key_exchange_modes extension.

Yours,
Daniel

 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:

  Client   Server

   Initial Handshake:
  ClientHello
  + key_share   >
  ServerHello
  + key_share
{EncryptedExtensions}
{CertificateRequest*}
   {Certificate*}
 {CertificateVerify*}
   {Finished}
< [Application Data*]
  {Certificate*}
  {CertificateVerify*}
  {Finished}>
<  [NewSessionTicket]
  [Application Data]<--->  [Application Data]


   Subsequent Handshake:
  ClientHello
  + key_share*
  + pre_shared_key  >
  ServerHello
 + pre_shared_key
 + key_share*
{EncryptedExtensions}
   {Finished}
< [Application Data*]
  {Finished}>
  [Application Data]<--->  [Application Data]

   Figure 3: Message Flow for Resumption and PSK
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Daniel Migault]

I believe the doc is fine as it is.
Yours,
Daniel

On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni 
wrote:

> > On Apr 12, 2019, at 7:28 PM, Christopher Wood 
> wrote:
> >
> > This is the working group last call for the "Deprecating TLSv1.0 and
> TLSv1.1” draft available at:
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> >
> > Please review the document and send your comments to the list by April
> 26, 2019.
>
> My concern is whether the time is yet nigh for TLS 1.0 to be disabled
> in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
> common to cause deprecation to do more harm than good via unnecessary
> downgrades to cleartext.
>
> I don't have survey numbers for SMTP TLS protocol versions across MTAs
> generally to shed light on this, perhaps someone does.  What I do have
> is numbers for those MTAs (not a representative sample) that have DANE
> TLSA records (so presumably a greater focus on security).
>
> The observed version frequencies are approximately:
>
> TLS 1.0:  1%
> TLS 1.1:  0%
> TLS 1.2: 87%
> TLS 1.3: 12%
>
> essentially regardless of whether I deduplicate by name, IP or name and IP.
> The respective sample sizes are 5435, 6938 and 7959.
>
> So if a DANE-enabled sender were to disable TLS 1.0 today, approximately
> 1% of the destination MX hosts would be broken and need remediation.  These
> handle just of 189 mostly small SOHO domains out of the ~1.1 million total
> DANE SMTP domains, but four handle enough email to show up on the Gmail
> SMTP transparency report:
>
>   tu-darmstadt.de
>   t-2.net
>   t-2.com
>   t-2.si
>
> So on the whole, the draft should proceed, but some caution may be
> appropriate
> outside the browser space, before operators start switching off TLS 1.0
> support.
>
> I don't see an operational considerations section.  Nor much discussion of
> "less mainstream" (than Web browser) TLS application protocols.  Would a
> few
> words of caution be appropriate, or is it expected that by the time the RFC
> starts to change operator behaviour the "market share" of TLS 1.0 will be
> substantially lower than I see today even with SMTP, XMPP, NTTP and the
> like.
>
> [ I would speculate that TLS 1.0's share is noticeably higher among MTAs
>   generally than among the bleeding-edge MTAs that have published DANE TLSA
>   RRs. ]
>
> --
> Viktor.
>
> ___
> 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

[TLS] netdev0x13 - ietf related topics

[Daniel Migault]

Hi,



Please find among many others some IETF related topics [1] that will be
discussed at netdev0x13 just before the IETF meeting in Pragues.



Early bird registration is open until February 20. 



Netdev 0x13 will be held at Hotel Grandium
 in Prague, this spring March 20th -
22th, 2019


Yours,

Daniel



[1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

[Daniel Migault]

I support the adoption as well, we need it for lurk.
Yours,
Daniel

On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich  wrote:

> I support adoption and I am sure OpenSSL will implement, or I will do it
> and make a PR.
>
> ___
> 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

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

[Daniel Migault]

I support the adoption.
Yours,
Daniel

On Sat, Aug 18, 2018 at 7:53 AM, Ira McDonald 
wrote:

> I support adoption.
>
> - Ira
>
>
> On Fri, Aug 17, 2018 at 1:32 PM, Sean Turner  wrote:
>
>> At the TLS@IETF102 session, there seemed to be some interest in adopting
>> draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to
>> determine whether there is WG consensus to adopt this draft as a WG item..
>> If you would like for this draft to become a WG document and you are
>> willing to review it as it moves through the process, then please let the
>> list know by 2359UTC 20180831.  If you are opposed to this being a WG
>> document, please say so (and say why).
>>
>> Note that we will suggest replacing “diediedie" with “deprecate" in the
>> adopted draft’s name to address the naming comment raised during the
>> meeting.
>>
>> Thanks,
>> Chris, Joe and Sean
>> ___
>> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing Protocol Invariants

[Daniel Migault]

The two mechanisms address different targets but overall I prefer the
design of the new proposal.
Yours,
Daniel

On Wed, Jun 13, 2018 at 4:29 PM, David Benjamin 
wrote:

> Are you asking about this new proposal (which still needs an amusing
> name), or the original GREASE mechanism?
>
> The original GREASE mechanism was only targetting ClientHello intolerance
> in servers. It's true that it uses specific values, and indeed there is
> nothing stopping buggy implementations from treating them differently. The
> thought then was ClientHello intolerance in servers is usually just
> accidental. It takes a certain willful ignorance to forget the default in
> your switch-case, and then go out of your way to special-case things,
> rather than recheck the spec as to what you're supposed to do. It was also
> meant to be lightweight (a one-time implementation cost and a one-time
> allocation). It's imperfect, but it does seem to help with the problem.
>
> This new proposal is targetting ServerHello intolerance problems. Rather
> than fixing a set of values initially, it regularly rerolls random values
> over time, with no fixed pattern. It should hopefully be more resilient to
> this sort of misbehavior. On the flip side, it is more work to maintain and
> only implementations that update sufficiently frequently can participate,
> whereas, in theory, anyone could deploy the original GREASE.
>
> On Wed, Jun 13, 2018 at 3:15 PM Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> I also support something is being done in this direction. I like the idea
>> of taking ephemeral non allocated code points.
>>
>> What is not so clear to me is how GREASE prevents a buggy implementations
>> from behaving correctly for GREASE allocated code points, while remaining
>> buggy for the other (unallocated). code points.
>> Yours,
>> Daniel
>>
>> On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini <
>> alessan...@ghedini.me> wrote:
>>
>>> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
>>> > Hi all,
>>> >
>>> > Now that TLS 1.3 is about done, perhaps it is time to reflect on the
>>> > ossification problems.
>>> >
>>> > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may
>>> be
>>> > incrementally rolled out in an existing compliant TLS 1.2 deployment.
>>> Yet
>>> > we had problems. Widespread non-compliant servers broke on the TLS 1.3
>>> > ClientHello, so versioning moved to supported_versions. Widespread
>>> > non-compliant middleboxes attempted to parse someone else’s
>>> ServerHellos,
>>> > so the protocol was further hacked to weave through their many
>>> defects..
>>>
>>> >
>>> > I think I can speak for the working group that we do not want to repeat
>>> > this adventure again. In general, I think the response to ossification
>>> is
>>> > two-fold:
>>> >
>>> > 1. It’s already happened, so how do we progress today?
>>> > 2. How do we avoid more of this tomorrow?
>>> >
>>> > The workarounds only answer the first question. For the second, TLS
>>> 1.3 has
>>> > a section which spells out a few protocol invariants
>>> > <https://tlswg.github.io/tls13-spec/draft-ietf-tls-
>>> tls13.html#rfc.section.9..3>.
>>> > It is all corollaries of existing TLS specification text, but hopefully
>>> > documenting it explicitly will help. But experience has shown
>>> specification
>>> > text is only necessary, not sufficient.
>>> >
>>> > For extensibility problems in servers, we have GREASE
>>> > <https://tools.ietf.org/html/draft-ietf-tls-grease-01>. This enforces
>>> the
>>> > key rule in ClientHello processing: ignore unrecognized parameters.
>>> GREASE
>>> > enforces this by filling the ecosystem with them. TLS 1.3’s middlebox
>>> woes
>>> > were different. The key rule is: if you did not produce a ClientHello,
>>> you
>>> > cannot assume that you can parse the response. Analogously, we should
>>> fill
>>> > the ecosystem with such responses. We have an idea, but it is more
>>> involved
>>> > than GREASE, so we are very interested in the TLS community’s feedback.
>>> >
>>> > In short, we plan to regularly mint new TLS versions (and likely other
>>> > sensitive parameters such as extensions), roughly every six weeks
>>> matching
>>> > Chrome’

Re: [TLS] Enforcing Protocol Invariants

[Daniel Migault]

I also support something is being done in this direction. I like the idea
of taking ephemeral non allocated code points.

What is not so clear to me is how GREASE prevents a buggy implementations
from behaving correctly for GREASE allocated code points, while remaining
buggy for the other (unallocated). code points.
Yours,
Daniel

On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini 
wrote:

> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> > ossification problems.
> >
> > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
> > incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
> > we had problems. Widespread non-compliant servers broke on the TLS 1.3
> > ClientHello, so versioning moved to supported_versions. Widespread
> > non-compliant middleboxes attempted to parse someone else’s ServerHellos,
> > so the protocol was further hacked to weave through their many defects.
> >
> > I think I can speak for the working group that we do not want to repeat
> > this adventure again. In general, I think the response to ossification is
> > two-fold:
> >
> > 1. It’s already happened, so how do we progress today?
> > 2. How do we avoid more of this tomorrow?
> >
> > The workarounds only answer the first question. For the second, TLS 1.3
> has
> > a section which spells out a few protocol invariants
> >  tls13.html#rfc.section.9..3>.
> > It is all corollaries of existing TLS specification text, but hopefully
> > documenting it explicitly will help. But experience has shown
> specification
> > text is only necessary, not sufficient.
> >
> > For extensibility problems in servers, we have GREASE
> > . This enforces
> the
> > key rule in ClientHello processing: ignore unrecognized parameters.
> GREASE
> > enforces this by filling the ecosystem with them. TLS 1.3’s middlebox
> woes
> > were different. The key rule is: if you did not produce a ClientHello,
> you
> > cannot assume that you can parse the response. Analogously, we should
> fill
> > the ecosystem with such responses. We have an idea, but it is more
> involved
> > than GREASE, so we are very interested in the TLS community’s feedback.
> >
> > In short, we plan to regularly mint new TLS versions (and likely other
> > sensitive parameters such as extensions), roughly every six weeks
> matching
> > Chrome’s release cycle. Chrome, Google servers, and any other deployment
> > that wishes to participate, would support two (or more) versions of TLS
> > 1.3: the standard stable 0x0304, and a rolling alternate version. Every
> six
> > weeks, we would randomly pick a new code point. These versions will
> > otherwise be identical to TLS 1.3, save maybe minor details to separate
> > keys and exercise allowed syntax changes. The goal is to pave the way for
> > future versions of TLS by simulating them (“draft negative one”).
> >
> > Of course, this scheme has some risk. It grabs code points everywhere.
> Code
> > points are plentiful, but we do sometimes have collisions (e.g. 26 and
> 40).
> > The entire point is to serve and maintain TLS’s extensibility, so we
> > certainly do not wish to hamper it! Thus we have some safeguards in mind:
> >
> > * We will document every code point we use and what it refers to. (If the
> > volume is fine, we can email them to the list each time.) New allocations
> > can always avoid the lost numbers. At a rate of one every 6 weeks, it
> will
> > take over 7,000 years to exhaust everything.
> >
> > * We will avoid picking numbers that the IETF is likely to allocate, to
> > reduce the chance of collision. Rolling versions will not start with
> 0x03,
> > rolling cipher suites or extensions will not be contiguous with existing
> > blocks, etc.
> >
> > * BoringSSL will not enable this by default. We will only enable it where
> > we can shut it back off. On our servers, we of course regularly deploy
> > changes. Chrome is also regularly updated and, moreover, we will gate it
> on
> > our server-controlled field trials
> >  mechanism.
> We
> > hope that, in practice, only the last several code points will be in use
> at
> > a time.
> >
> > * Our clients would only support the most recent set of rolling
> parameters,
> > and our servers the last handful. As each value will be short-lived, the
> > ecosystem is unlikely to rely on them as de facto standards. Conversely,
> > like other extensions, implementations without them will still
> interoperate
> > fine. We would never offer a rolling parameter without the corresponding
> > stable one.
> >
> > * If this ultimately does not work, we can stop at any time and only have
> > wasted a small portion of code points.
> >
> > * Finally, if the working group is open to it, these values could be

Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

[Daniel Migault]

IESG approval seems also fine to me. Hopefully ciphers may not be used at
the time they are deprecated.

Yours,
Daniel

On Wed, Nov 22, 2017 at 12:13 PM, Sean Turner  wrote:

> Funny I never thought about going down, but I guess we should ;) I think
> the premise we want here is hard to get a Yes (whether new or upgrade) and
> somewhat easier than that to go down but it can’t be done in the dark so 4
> would work. This kind of works out because people are motivated to get
> ciphers specified, but very much less so to de-specify them.
>
> spt
> > On Nov 21, 2017, at 18:54, Stephen Farrell 
> wrote:
> >
> >
> >
> > On 21/11/17 23:39, Martin Thomson wrote:
> >> IESG action seems appropriate for both.
> >
> > I'm fairly sure the WG discussed the No->Yes (or new Yes)
> > before and wanted standards action for that. I'd guess
> > that changing that might take some discussion. (FWIW, I'd
> > not support that change myself but maybe others would.)
> >
> > If the No->Yes stuff doesn't change I'll take you as
> > arguing for a (4) below but correct me if that's wrong.
> >
> > Cheers,
> > S.
> >
> >> If we could include guidance
> >> around this (values with Yes should only include those for which the
> >> community currently has consensus are worth having available at the
> >> current time), tat would be awesom>
> >> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
> >>  wrote:
> >>>
> >>> Hiya,
> >>>
> >>> I just posted a draft shepherd write-up for this [1]. (The
> >>> write-up text was mostly written by Sean as it happens - for
> >>> which he has my thanks as it's boring as hell to do that:-)
> >>>
> >>> There are nits but only one substantive question that I don't
> >>> recall the WG discussing before (but maybe I'm forgetting).
> >>>
> >>> What is needed to change from Recommended == Yes down to
> >>> Recommended == No? Does that need a standards action (e.g.
> >>> with an RFC) or just IETF review or even maybe just IESG
> >>> action?
> >>>
> >>> In the current draft write-up I've put in the first as a
> >>> placeholder, as that's symmetric with the No->Yes change but
> >>> I think IESG action is probably ok if the WG wanted that as
> >>> the IESG probably won't go crazy and will likely do as the
> >>> WG want in such cases. If the WG do want to write a specific
> >>> foo-no-longer-recommended RFC it can do that in all cases,
> >>> and of course Yes->No transitions could be documented in an
> >>> RFC that documents a "replacement" Yes entry.
> >>>
> >>> So, unless this was already discussedanswers on a postcard
> >>> please - which'd we like:
> >>>
> >>> (1) say nothing (as in -02 draft)
> >>> (2) say standards action is required for a Yes->No transition
> >>> (3) say IETF review (i.e. an IETF last call) is required for a
> >>>Yes->No transition
> >>> (4) say IESG action is required for a Yes->No transition
> >>> (5) something else
> >>>
> >>> And as a reminder the Recommended column is not about crypto
> >>> quality but is about things for which we have consensus that
> >>> they ought be widely implemented and available at the current
> >>> point in time. Those are related things but Recommended == No
> >>> does not imply crap-crypto even if crap-crypto will hopefully
> >>> imply Recommended == No.
> >>>
> >>> If nobody says anything I'll chat with Kathleen, Sean and Joe
> >>> and we'll pick a thing and that'll doubtless be quibbled about
> >>> during directorate reviews and IESG processing as these things
> >>> always are;-)
> >>>
> >>> But since I'd hope implementers will care about keeping up to
> >>> date with the set of Recommended == Yes things, I do hope that
> >>> folks are willing to express a preference here.
> >>>
> >>> Cheers,
> >>> S.
> >>>
> >>> [1]
> >>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> shepherdwriteup/
> >>>
> >>>
> >>> ___
> >>> 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
>
> ___
> 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

Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

[Daniel Migault]

Hi Eric,

Thank you for reviewing the document. Given your second comment, I suspect
you are reading the version 04 while the current version is version 05 [1].
I believe your comments have been addressed in the version 05.However let
me know if you have other concerns.

Regarding TLS1.3. we were asked to position the new code points toward
TLS1.3, but I guess that was at the time the version was not indicated in
the title, so in principle we could remove these references.I believe the
text in version 05 address your comment, but here are the current version
still cites TLS 1.3 in the following sections:

   - introduction: """AEAD algorithms that combine encryption and integrity
   protection are strongly recommended for (D)TLS [RFC7525
   ] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13
   
].
   """. Would you prefer to remove "and non-AEAD algorithms are forbidden to
   use in TLS 1.3 [I-D.ietf-tls-tls13
   

   ]" or it is fine to leave it as it is ?
   - section 3: """ Cipher suites TLS_AES_128_GCM_SHA256,
   TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256
   are used to support equivalent functionality in TLS 1.3 [
   I-D.ietf-tls-tls13
   
].
   """. Would you prefer to have all mentioned text being removed or is it
   fine to leave it as it is ?

Regarding the reference to the PRF of TLS 1.1, I think it concerns the text
below which has been removed in the version 05.

"""

   [...]  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.   The cipher suites defined in this document
make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246 ] and DTLS 1.2
[RFC6347 ].  Earlier versions of
TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246
] and TL1.2
   [RFC4346 ] splits the
pre-master in two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and pre-master are treated by
   distinct hash function with distinct properties.  This may introduce
   vulnerabilities over the expected security provided by the
   constructed pre-master.  As such TLS 1.0 and TLS 1.1 should not be
   used with ECDHE_PSK.
"""

Yours,

Daniel

[1] https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05

On Thu, Aug 10, 2017 at 10:39 AM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-05: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> COMMENT:
> --
>
> The citations to TLS 1.3 still seem pretty muddled. I think you
> should just stop referencing and discussing 1.3.
>

> S 2.
> I'm not sure that the discussion of the PRF is helpful here in
> mandating the non-use of these cipher suites with TLS 1.1 and
> below.
>
>


>
> ___
> 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

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

 Hi,

Please find the version the secretariat just published. I believe all
comments have been addressed. Thank you all for the reviews!

Yours,

Daniel



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, May 25, 2017 9:32 AM
To: John Mattsson <john.matts...@ericsson.com>; Daniel Migault
<daniel.miga...@ericsson.com>
Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-05.txt





A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-05.txt

has been successfully submitted by Daniel Migault and posted to the IETF
repository.



Name:  draft-ietf-tls-ecdhe-psk-aead

Revision:  05

Title:  ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security (TLS) Protocol version 1.2

Document date:   2017-05-24

Group:  tls

Pages:   7

URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-05.txt

Status:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-05

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-05



Abstract:

   This document defines several new cipher suites for the Transport

   Layer Security (TLS) protocol version 1.2.  The cipher suites are all

   based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared

   Key (ECDHE_PSK) key exchange together with the Authenticated

   Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-

   CCM.  PSK provides light and efficient authentication, ECDHE provides

   forward secrecy, and AES-GCM and AES-CCM provides encryption and

   integrity protection.










Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.



The IETF Secretariat

On Wed, May 24, 2017 at 6:29 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> On 25 May 2017 at 07:43, Daniel Migault <daniel.miga...@ericsson.com>
> wrote:
> > From your response I understand you do not request changes.
>
>
> I am requesting changes. Just say that
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 uses AEAD_AES_128_GCM, and so
> forth.  It's not hard to be explicit.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Thanks Spencer for your review. Actually the scope has always been TLS1.2
only. I confirm version 05 have addressed Erik's comments.
Yours,
Daniel

On Wed, May 24, 2017 at 4:03 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Wed, May 24, 2017 at 4:49 PM, Spencer Dawkins
>  wrote:
> > Spencer Dawkins has entered the following ballot position for
> > draft-ietf-tls-ecdhe-psk-aead-04: 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 https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Ciphersuite drafts for TLS are usually above my pay grade, but I
> > understand most of EKR's Discuss, and agree with Adam's suggestion to
> > change the document title to "ECDHE_PSK with AES-GCM and AES-CCM Cipher
> > Suites for Transport Layer Security Version 1.2 (TLS 1.2)" at an absolute
> > minimum.
>
> The shepherd proposed a resolution that should clear up the discuss points.
> >
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

>From your response I understand you do not request changes.
Yours,
Daniel

On Wed, May 24, 2017 at 4:24 PM, Martin Thomson 
wrote:

> On 25 May 2017 at 07:14, Joseph Salowey  wrote:
> > [Joe] It seems that a reasonable interpretation of the text is that the
> AEAD
> > constructs will pair with the cipher suite that share the same name.  Do
> you
> > still think we need to provide an explicit mapping between the two?
>
>
> Reasonable, sure, even obvious.  I've learned that reasonable doesn't
> work always.  Note that the order that the AEADs are listed doesn't
> match the order of the cipher suites.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

Hi,

Thank Joe for the clarification. I removed section 4 and instead have the
following section 3. This is the version 06.

I will post it as soon as the datatracker allows me to submit a new
version, so please let me know if that address all concerns.

Yours,
Daniel

3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

   The cipher suites defined in this document are based on the AES-GCM
   and AES-CCM Authenticated Encryption with Associated Data (AEAD)
   algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
   defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

   Messages and premaster secret construction in this document are
   defined in [RFC5489].  The ServerKeyExchange and ClientKeyExchange
   messages are used and the premaster secret is computed as for the
   ECDHE_PSK key exchange.  The elliptic curve parameters used in in the
   Diffie-Hellman parameters are negotiated using extensions defined in
   [I-D.ietf-tls-rfc4492bis].

   For TLS 1.2, the following cipher suites are defined:

   TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD,0xTBD};

   The assigned code points can only be used for TLS 1.2.

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].



On Wed, May 24, 2017 at 11:03 AM, Joseph Salowey <j...@salowey.net> wrote:

> Hi Daniel,
>
> Thanks for putting this revision together.  The original text in draft 4
> went beyond the scope of what should be in the document (I was too hasty in
> my review of the document and discussion on the list).   Your current
> proposal is an improvement, but it still discusses behavior that could
> either conflict with other documents or discusses behavior that is not in
> scope.
>
> My suggestion is to replace section 4 with the following paragraph (I
> think this is similar to what Martin suggests):
>
> "The cipher suites defined in this document MUST NOT be negotiated for any
> version of (D)TLS other than TLS 1.2.  Servers MUST NOT select one of these
> cipher suites when selecting TLS version other than TLS 1.2.  A client MUST
> treat the selection of these cipher suites in combination with a different
> version of TLS as an error and generate a fatal 'illegal_parameter' TLS
> alert."
>
> I think it would also be OK to add the following to point readers to
> equivalent ciphers in 1.3.  Here is some suggested text that could go in
> the revised section 4:
>
> "Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to support
> equivalent functionality in TLS 1.3 [TLS 1.3]."
>
> Thanks,
>
> Joe
>
>
> On Wed, May 24, 2017 at 7:04 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> Hi Martin,
>>
>> Thank you for your review. Some comment were about text in the
>> applicability section. I think I agree with you that this section details
>> and clarifies  the following sentence of the previous section:  """ The
>> assigned code points can only be used for TLS 1.2.""". Most of the text of
>> this section has been added in order to address comments, thus in order to
>> make this section helpful for many readers, I prefer to keep most of the
>> text you mentioned as not useful.
>>
>> Please see inline for more detail responses and let me know if that
>> address your comments.
>>
>> Yours,
>> Daniel
>>
>> On Wed, May 24, 2017 at 12:09 AM, Martin Thomson <
>> martin.thom...@gmail.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> This removes the offending text.
>>>
>>> This is incorrect:
>>>
>>> > Clients MUST NOT offer one of these cipher suites with a (D)TLS
>>> version that differs from TLS 1.2.
>>>
>>> It should be possible to offer these when attempting to negotiate TLS
>>> 1.3.  The server simply cannot negotiate these cipher suites if it
>>> chooses to use 1.3.  I'd remove that sentence (and the one following
>>> it, since it's redund

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

r than 1.2. More specifically, previous version do not support AEAD,
but this may not prevent someone using AEAD with these versions. The reason
provided is not AEAD related but PSK related. I believe it is useful to
explicitly justify why the cipher suites defined in the document should not
be used with previous TLS versions. The text has bee suggested by the
secdir and I would prefer to keep it, unless there is a strong willingness
to remove it.


> Nits:
> s/pre-master(| secret)/premaster secret/g
>

Corrected: The text only have premaster secret.


> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
> means to use AEAD_AES_128_GCM (and the same for the other
> ciphersuites).  I mention this because the order in which the AEAD
> algorithms are mentioned is different to the order of the ciphersuites
> in the list.
>
>
Unless I miss your comment, I believe the section 3 already addresses it.
If not please let me knoe what text you would like to see.

"""
3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

   The cipher suites defined in this document are based on the AES-GCM
   and AES-CCM Authenticated Encryption with Associated Data (AEAD)
   algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
   defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

"""

>
> On 24 May 2017 at 12:37, Daniel Migault <daniel.miga...@ericsson.com>
> wrote:
> > re-sending with the version 05 but removing the diff to be under the 100
> KB
> > limit.
> > Yours,
> > Daniel
> >
> > On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
> > <daniel.miga...@ericsson.com> wrote:
> >>
> >> Hi Eric,
> >>
> >> Thank you for the feed backs. The version 05 contains all text changes
> you
> >> agreed. In addition, the text explaining dictionary/brute force has been
> >> removed and replace by a reference to 4279. The recommendation
> regarding to
> >> all PSK ciphers has been limited to the one of the document.  Please see
> >> inline for more details.
> >>
> >> For some reasons I am not able to validate the submission of version
> 05. I
> >> have attached the diff with version 04 as well as the locally generated
> >> version 05.
> >>
> >> Yours,
> >> Daniel
> >>
> >> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla <e...@rtfm.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
> >>> <daniel.miga...@ericsson.com> wrote:
> >>>>
> >>>> Hi Eric,
> >>>>
> >>>> Thank you for your reviews. Please see my responses inline. If you
> agree
> >>>> with the text I will update the draft.
> >>>>
> >>>> Yours,
> >>>> Daniel
> >>>>
> >>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <e...@rtfm.com> wrote:
> >>>>>
> >>>>> Eric Rescorla has entered the following ballot position for
> >>>>> draft-ietf-tls-ecdhe-psk-aead-04: 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://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>
> >>>>>
> >>>>> The document, along with other ballot positions, can be found here:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> >>>>>
> >>>>>
> >>>>>
> >>>>> 
> --
> >>>>> DISCUSS:
> >>>>> 
> --
> >>>>>
> >>>>> The following text appears to have been added in -04
> >>>>>
> >>>>>A server receiving a ClientHello and a client_version indicating
> >>>>>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites
> from
> >>>>>this document in ClientHello.cipher_suites can safely assume that
> >>>>> the
> >>>>>client s

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi Adam,

The text you mention is from version 04. Version 05 has been submitted, but
is somewhere in the datatracker. For some reason I am not able to confirm
the submission, so I have attached it to my response to Eric. The text of
the current version 05 is:

Yours,
Daniel
"""
4. Applicable TLS Versions

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
   of these cipher suites with a (D)TLS version that differs from TLS
   1.2.  Servers MUST NOT select one of these cipher suites with a TLS
   version that differs from TLS 1.2.  A client MUST treat the selection
   of these cipher suites in combination with a version of TLS as an
   error and generate a fatal 'illegal_parameter' TLS alert.




Mattsson & Migault  Expires November 24, 2017   [Page 3]
^L
Internet-Draft   ECDHE_PSK_AEAD May 2017


   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
   [RFC4346] split the pre-master into two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and ECDHE shared secret are treated
   by distinct hash function with distinct properties.  This may
   introduce vulnerabilities over the expected security provided by the
   constructed pre-master.  As such, all ECDHE_PSK ciphers, including
   those defined in this document, SHOULD NOT be negotiated in TLS
   versions prior to 1.2.
"""

On Tue, May 23, 2017 at 10:48 PM, Adam Roach <a...@nostrum.com> wrote:

> On 5/23/17 9:33 PM, Daniel Migault wrote:
>
>> The current version does not consider that proposing the cipher suites of
>> the document implicitly assumes the client supports TLS1.2.
>>
>
> Really? Can you clarify the meaning of the following passage? Because I
> can't read it in any way other than to contradict your assertion above:
>
>
>A server receiving a ClientHello and a client_version indicating
>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>this document in ClientHello.cipher_suites can safely assume that the
>client supports TLS 1.2 and is willing to use it.
>
>
>
> /a
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi,
Thanks for your review. I believe version 05 address Eric comments..
Yours,
Daniel

On Tue, May 23, 2017 at 6:12 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> COMMENT:
> --
>
> I support Ekr's DISCUSS position.
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

re-sending with the version 05 but removing the diff to be under the 100 KB
limit.
Yours,
Daniel

On Tue, May 23, 2017 at 9:28 PM, Daniel Migault <daniel.miga...@ericsson.com
> wrote:

> Hi Eric,
>
> Thank you for the feed backs. The version 05 contains all text changes you
> agreed. In addition, the text explaining dictionary/brute force has been
> removed and replace by a reference to 4279. The recommendation regarding to
> all PSK ciphers has been limited to the one of the document.  Please see
> inline for more details.
>
> For some reasons I am not able to validate the submission of version 05. I
> have attached the diff with version 04 as well as the locally generated
> version 05.
>
> Yours,
> Daniel
>
> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <
>> daniel.miga...@ericsson.com> wrote:
>>
>>> Hi Eric,
>>>
>>> Thank you for your reviews. Please see my responses inline. If you agree
>>> with the text I will update the draft.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>>> Eric Rescorla has entered the following ballot position for
>>>> draft-ietf-tls-ecdhe-psk-aead-04: 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://www.ietf.org/iesg/stat
>>>> ement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>>>
>>>>
>>>>
>>>> --
>>>> DISCUSS:
>>>> --
>>>>
>>>> The following text appears to have been added in -04
>>>>
>>>>A server receiving a ClientHello and a client_version indicating
>>>>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>>>this document in ClientHello.cipher_suites can safely assume that
>>>> the
>>>>client supports TLS 1.2 and is willing to use it.  The server MUST
>>>>NOT negotiate these cipher suites with TLS protocol versions earlier
>>>>than TLS 1.2.  Not requiring clients to indicate their support for
>>>>TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>>>>improves the interoperability in the installed base and use of TLS
>>>>1.2 AEAD cipher suites without upsetting the installed base of
>>>>version-intolerant TLS servers, results in more TLS handshakes
>>>>succeeding and obviates fallback mechanisms.
>>>>
>>>> This is a major technical change from -03, which, AFAIK, prohibited
>>>> the server from negotiating these algorithms with TLS 1.1 and below
>>>> and maintained the usual TLS version 1.2 negotiation rules.
>>>>
>>>> This is a very material technical change. I don't consider it wise,
>>>> but in any case it would absolutely need WG consensus, which I
>>>> don't believe that it has given the recent introduction.
>>>>
>>>
>>> I agree that the text is a technical change, and that it may not be
>>> appropriated to do so now. The reason I included it was that it was conform
>>> to the previous text, but I agree that implicit assumption of version 1.2
>>> may need some additional discussion especially regarding RFC5246 Appendix
>>> E. Unless you prefer further discussion I assume the text below address
>>> your concern.
>>>
>>> The cipher suites defined in this document MUST NOT be negotiated for
>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
>>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
>>> Servers MUST NOT select one of these cipher suites with a TLS version that
>>> differs from TLS 1.2. A client MUST treat the selection of these cipher
>>> suites in combination with a version of TLS as an error and generate a
>&

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi Martin,

The current version does not consider that proposing the cipher suites of
the document implicitly assumes the client supports TLS1.2. However, if
people think there is an advantage of adding this I am fine this being
discussed and  added in the next versions.

Yours,
Daniel

On Tue, May 23, 2017 at 7:10 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> On 24 May 2017 at 08:04, Daniel Migault <daniel.miga...@ericsson.com>
> wrote:
> > So I have propose a fall back to the latest version. However, if we agree
> > this is a better approach, I am fine adding it to the document.
>
>
> Not sure what you mean by this.  If you mean removing the offending
> paragraph, that seems best.
>
> It's OK for these suites to be 1.2 only.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Thank you for the clarifying text. I have added it on my local copy.
Yours,
Daniel

On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk <ka...@mit.edu> wrote:

> Sorry for the slow reply.
>
> On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> > Thank you,
> >
> > Your comments have all been addressed. I have one remaining
> clarification.
> > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and
> not
> > only for the cipher suites of the draft. In your opinion do we clarify
> > this, and should we use something else than SHOULD NOT ?
>
> It's somewhat awkward, as what we really want to do is Update RFC
> 5489 to add this prohibition there.  But, that's more process to
> jump through and this document is already at a late stage, so I do
> not actually propose doing that.  I would be okay saying
>
>   As such, all ECDHE_PSK ciphers, including those defined outside
>   this document, SHOULD NOT be negotiated in TLS versions prior to
>   1.2.
>
> to match up with the MUST NOT text we have for these new ciphers.
> (Taking into account Martin's text that the prohibition is on
> negotiating them, but offering them in a ClientHello that also
> offers the old version is okay.)
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault]

Hi,

So I have propose a fall back to the latest version. However, if we agree
this is a better approach, I am fine adding it to the document.

Yours,
Daniel

On Tue, May 23, 2017 at 3:34 PM, Martin Rex  wrote:

> Adam Roach wrote:
> > draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> >
> > --
> > COMMENT:
> > --
> >
> > I agree with EKR's discuss -- specifying semantics for these ciphersuites
> > with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
> > which servers are encouraged to infer 1.2 support even in the absence of
> > explicit indication) is a bit baffling.
>
> It encourages (but does not require) servers to infer 1.2 support
> from _very_explicit_ information: the offering of TLSv1.2-only TLS
> ciphersuites is the very same TLS ClientHello handshake message.
>
> We know since rfc5746 that the most reliable scheme to indicate support
> for certain TLS protocol features is a cipher suite value.  It is far
> from rocket science to infer support for 1.2 from 1.2-only cipher
> suite codepoints in ClientHello.cipher_suites.
>
>
>
> I just realized that I suggested removal of a description of client
> behaviour that can, and should remain in the document (I'm sorry):
>
> A client MUST treat the selection of these cipher
>   suites in combination with a version of TLS that does not support
>   AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
>   'illegal_parameter' TLS alert.
>
>
> -Martin
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Daniel Migault]

Hi Eric,

Thank you for your reviews. Please see my responses inline. If you agree
with the text I will update the draft.

Yours,
Daniel

On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: 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://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> DISCUSS:
> --
>
> The following text appears to have been added in -04
>
>A server receiving a ClientHello and a client_version indicating
>(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>this document in ClientHello.cipher_suites can safely assume that
> the
>client supports TLS 1.2 and is willing to use it.  The server MUST
>NOT negotiate these cipher suites with TLS protocol versions earlier
>than TLS 1.2.  Not requiring clients to indicate their support for
>TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>improves the interoperability in the installed base and use of TLS
>1.2 AEAD cipher suites without upsetting the installed base of
>version-intolerant TLS servers, results in more TLS handshakes
>succeeding and obviates fallback mechanisms.
>
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.
>
> This is a very material technical change. I don't consider it wise,
> but in any case it would absolutely need WG consensus, which I
> don't believe that it has given the recent introduction.
>

I agree that the text is a technical change, and that it may not be
appropriated to do so now. The reason I included it was that it was conform
to the previous text, but I agree that implicit assumption of version 1.2
may need some additional discussion especially regarding RFC5246 Appendix
E. Unless you prefer further discussion I assume the text below address
your concern.

The cipher suites defined in this document MUST NOT be negotiated for
any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
these cipher suites with a (D)TLS version that differs from TLS 1.2.
Servers MUST NOT select one of these cipher suites with a TLS version that
differs from TLS 1.2. A client MUST treat the selection of these cipher
suites in combination with a version of TLS as an error and generate a
fatal 'illegal_parameter' TLS alert. 

>
> The discussion of dictionary attacks here seems inferior to that
> in 4279. In particular, you only need to actively attack one
> connection to capture the data you need for a brute force attack
> despite the text there referring to trying "different keys".
> Please correct that.
>
> I believe the text below address your concern:

OLD:
Use of Pre-Shared Keys of limited entropy may allow an active
attacker attempts to connect to the server and try different keys.
For example, limited entropy may be provided by using a short PSK in which
case an attacker may perform a brute-force attack. Another example
includes the use of a PSK  chosen by a human which thus may be exposed to
dictionary attacks.

NEW:
Pre-Shared Keys security relies on its associated entropy, and it is
RECOMMENDED to follow  to ensure the PSK has enough
entropy. Possible reasons for low entropy includes PSK chosen by humans or
PSK of small length as well as using random generators with limited
entropy. 

PSK of limited entropy may allow an attacker to test different PSK
values against a valid output such as master secret or any output derived
from it. In this document, the master secret is generated using the PSK as
well as the ECDHE shared secret. The use of ECDHE limits the possibilities
of passive eavesdropping attackers, as the ECDHE shared secret is not
expected to be derived from the observed ECDH parameters. As a result,
passive eavesdropping is unlikely to happen, and the collection of all
necessary material relies on an active attack.
An active attacker may collect the necessary material by setting a TLS
session as a client with the legitimate server. One PSK is tested for each
session, and a match occurs when key exchange succeeds. On the other hand,
an active attacker may also consider gathering the necessary information
for offline computation. One way consists in getting a legitimate client to
establish a connection with the attacker. It is also assumed 

Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

[Daniel Migault]

Thanks I will add these by the end of the day.
Yours,
Daniel

On Mon, May 22, 2017 at 1:56 PM, Benjamin Kaduk <bka...@akamai.com> wrote:

> Thanks for the updates; the new revision addresses my concerns raised in
> the secdir review.
>
> However,
>
> % In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
> % [RFC4346] splits the pre-master in two parts.
>
> s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master secret
> into two parts".
>
> % the PSK and pre-master are treated by
> % distinct hash function with distinct properties.
>
> s/pre-master/ECDHE shared secret/?
>
> -Ben
>
>
> On 05/19/2017 03:18 PM, Daniel Migault wrote:
>
> Hi,
>
> Thank you to all reviewers for their feed backs. Please find the latest 
> version, which as far as I know includes all comments. Comments were not 
> controversial. In order to raise next reviews I am raising aspects that might 
> need a bit more attention.
>
> 1)  The current document mentions I-D.ietf-tls-rfc4492bis and 
> I-D.ietf-tls-tls13 as normative. We can wait for these documents to become 
> RFCs, but we can also dowref them to informational reference if we want to 
> move that document forward. I will leave the AD to decide, and changes if 
> needed can be done by the RFC -editor
>
> 2)  Section 4 has the following text:
>
> """In the case of ECDHE_PSK authentication, the PSK and pre-master are 
> treated by distinct hash function with distinct properties.  This may 
> introduce vulnerabilities over the expected security provided by the 
> constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be  used with 
> ECDHE_PSK. """
>
> With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suites 
> defined in the document.  I just want to make sure we are ok with the last 
> sentence.
>
> Yours,
> Daniel
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org 
> <internet-dra...@ietf.org>]
> Sent: Friday, May 19, 2017 4:03 PM
> To: John Mattsson <john.matts...@ericsson.com> <john.matts...@ericsson.com>; 
> Daniel Migault <daniel.miga...@ericsson.com> <daniel.miga...@ericsson.com>; 
> tls-cha...@ietf.org
> Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
>
>
> A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
>
> Name: draft-ietf-tls-ecdhe-psk-aead
> Revision: 04
> Title:ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for 
> Transport Layer Security (TLS)
> Document date:2017-05-18
> Group:tls
> Pages:8
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04
>
> Abstract:
>This document defines several new cipher suites for the Transport
>Layer Security (TLS) protocol.  The cipher suites are all based on
>the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>(ECDHE_PSK) key exchange together with the Authenticated Encryption
>with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>provides light and efficient authentication, ECDHE provides forward
>secrecy, and AES-GCM and AES-CCM provides encryption and integrity
>protection.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> 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

[TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

[Daniel Migault]

Hi, 

Thank you to all reviewers for their feed backs. Please find the latest 
version, which as far as I know includes all comments. Comments were not 
controversial. In order to raise next reviews I am raising aspects that might 
need a bit more attention.  

1)  The current document mentions I-D.ietf-tls-rfc4492bis and 
I-D.ietf-tls-tls13 as normative. We can wait for these documents to become 
RFCs, but we can also dowref them to informational reference if we want to move 
that document forward. I will leave the AD to decide, and changes if needed can 
be done by the RFC -editor

2)  Section 4 has the following text:

"""In the case of ECDHE_PSK authentication, the PSK and pre-master are treated 
by distinct hash function with distinct properties.  This may introduce 
vulnerabilities over the expected security provided by the constructed 
pre-master. As such TLS 1.0 and TLS 1.1 should not be  used with ECDHE_PSK. """

With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suites 
defined in the document.  I just want to make sure we are ok with the last 
sentence. 

Yours, 
Daniel

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, May 19, 2017 4:03 PM
To: John Mattsson <john.matts...@ericsson.com>; Daniel Migault 
<daniel.miga...@ericsson.com>; tls-cha...@ietf.org
Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt


A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF 
repository.

Name:   draft-ietf-tls-ecdhe-psk-aead
Revision:   04
Title:  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport 
Layer Security (TLS)
Document date:  2017-05-18
Group:  tls
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-04.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides forward
   secrecy, and AES-GCM and AES-CCM provides encryption and integrity
   protection.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Thank you,

Your comments have all been addressed. I have one remaining clarification.
In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not
only for the cipher suites of the draft. In your opinion do we clarify
this, and should we use something else than SHOULD NOT ?

Thanks for the reviews!

Yours,
Daniel

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities over
> the expected security provided by the constructed pre-master. As such
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if
you don't think it's useful.  (BTW, I think we are still TLS1.0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)

On Fri, May 19, 2017 at 12:27 PM, Benjamin Kaduk <ka...@mit.edu> wrote:

> On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> > Hi Benjamin,
> >
> > Thank you for the review. Please find my comments inline and let me know
> if
> > you agree with the proposed text. I believe the only point not addressed
> > concerns the addition of CCM-256 which has been remove after discussion
> > during the WGLC.
> >
> > Thanks you for the review,
> >
> > Yours,
> > Daniel
> >
> > On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk <ka...@mit.edu> wrote:
> >
> > > Hi all,
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> > > IESG.  These comments were written primarily for the benefit of the
> > > security area directors.  Document editors and WG chairs should
> > > treat these comments just like any other last call comments.
> > >
> > > This document is ready with nits.
> > >
> > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> > > space, thought of as a cross product of key exchange and
> > > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> > > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> > > not quite this one.
> > >
> > > That said, it seems a little silly to only partially fill the gap
> > > (by omitting the AES_256_CCM* cipher suites), even though there is
> > > not currently demand for them.
> > >
> > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and
> removed
> > after  the WGLC. [0] The issue was whether or not introducing new ciphers
> > not supported by TLS1.3. In 01, we though of adding the code point for
> > TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
> > the cipher suites proposed.In case of needs these could still be
> supported
> > later by TLS1.3. The consensus seems to not introduce ciphers that would
> > not be handled by TLS1.3. If the WG decides otherwise, these could still
> be
> > added.
> >
> > [0]
> > https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?
> qid=6e4713be1d71bae6718c6e6e6c4b8007
>
> That seems like a reasonable position for the WG to take, given how
> close TLS 1.3 is to publication.  (It would also be reasonable to
> define the full cross-product for TLS 1.2 only and have TLS 1.3 just
> use a subset, but I have no real preference.)
>
> >
> > > This document is just assembling pieces that were already specified
> > > elsewhere, so it need not contain much detail itself, which is fine.
> > > That said, I think section 3 should probably state explicitly which
> > > pieces it uses, instead of a vague reference of being "based on RFC
> > > 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> > > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> > > computed in the same manner as for ECDHE_PSK key exchange in RFC
> > > 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> > > does not cover ECDHE_PSK.)
> > >
> >
> > MGLT: I agree we coudl be more explicit, here are the changes I propose.
> I
> > believe it address your purpose.
> >
> > OLD:
> >
> > Messages and pre-master secret construction in this
> > document are based on [RFC4279 <https://tools.ietf.org/html/rfc4279>]

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Martin,

Thank you for the proposed text. It was very clear and I took it entirely,
just changing s/TLSv1/TLS 1/.

Yours,
Daniel


The current text is as follows:



 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS 1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS 1.0
 and TL1.2  splits the
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PSK.

A client that offers the cipher suites from this document in
ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 for the current session.  If the
client does not support TLS 1.2 or is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any of these cipher suites with a lower
protocol version than (3,3) "TLS 1.2" in ClientHello.client_version.

A server receiving a ClientHello and a client_version indicating
(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
this document in ClientHello.cipher_suites can safely assume that the
client supports TLS 1.2 and is willing to use it. The server MUST NOT
negotiate these cipher suites with TLS protocol versions earlier than
TLS 1.2. Not requiring clients to indicate their support for TLS 1.2
cipher suites exclusively through ClientHello.client_hello improves the
interoperability in the installed base and use of TLS 1.2 AEAD cipher
suites without upsetting the installed base of version-intolerant TLS
servers, results in more TLS handshakes succeeding and obviates fallback
mechanisms.


On Fri, May 19, 2017 at 10:17 AM, Martin Rex  wrote:

> Benjamin Kaduk wrote:
> >
> > Some other editorial nits follow.
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > versions prior to 1.2" should probably clarify that "these" cipher
> > suites are the new ones specified by this document.
>
>
> This reminds me of the specification goofs in several TLSv1.2-related
> documents about AEAD cipher suites which are responsible for the viability
> of the POODLE attack and other exploitable fallback hacks.
>
> It would be much preferable to avoid/fix those problems and facilitate
> the migration to and use of TLSv1.2 without failing TLS handshakes and
> band aids such as TLS_FALLBACK_SCSV
>
>
> Suggested improvement:
>
>The cipher suites defined in this document make use of the
>authenticated encryption with additional data (AEAD) defined in TLS
>1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
>have support for AEAD and consequently, these cipher suites MUST NOT
> -  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
> -  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
> -  which select an earlier version of TLS MUST NOT select one of these
> -  cipher suites.  A client MUST treat the selection of these cipher
> -  suites in combination with a version of TLS that does not support
> -  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
> -  'illegal_parameter' TLS alert.
> +   A client that offers
> +  the cipher suites from this document in ClientHello.cipher_suites
> +  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
> +  ClientHello.client_version MUST support TLSv1.2 and MUST accept
> +  the server to negotiate TLSv1.2 for the current session.  If the
> +  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
> +  then this client MUST NOT offer any of these cipher suites with a
> +  lower protocol version than (3,3) "TLSv1.2" in
> ClientHello.client_version.
> +  A server receiving a ClientHello and a client_version indicating
> +  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and 

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Benjamin and Dave,

Thanks for the clarification. Considering also Roman' s and Ben' s comments
the section is built as follow. 1) Limit cipher suites to TLS1.2, 2)
explain how TLS1.3 and higher version negotiate them 3) bring all
explanation foe the previous versions.

Yours,
Daniel

The text is as follows:

 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS1.0
 and TL1.2  splits teh
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE_PSK.  Clients MUST NOT offer these
cipher suites defined in this document if they do not offer TLS 1.2 or
later. Servers that select an earlier version of TLS MUST NOT select one
of these cipher suites. A client MUST treat the selection of these
cipher suites in combination with a version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' TLS alert.




On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk  wrote:

> On 05/19/2017 02:16 AM, Dave Garrett wrote:
>
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.
>
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>
>
>
> That's probably best, yes.  The interaction between this document and TLS
> 1.3 is a little weird, and it's not entirely clear to me that this one
> needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all
> the relevant messages and key hierarchy and such.
>
> -Ben
>
> ___
> 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

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Benjamin,

Thank you for the review. Please find my comments inline and let me know if
you agree with the proposed text. I believe the only point not addressed
concerns the addition of CCM-256 which has been remove after discussion
during the WGLC.

Thanks you for the review,

Yours,
Daniel

On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:

> Hi all,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> This document is ready with nits.
>
> Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> space, thought of as a cross product of key exchange and
> cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> not quite this one.
>
> That said, it seems a little silly to only partially fill the gap
> (by omitting the AES_256_CCM* cipher suites), even though there is
> not currently demand for them.
>
> MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
after  the WGLC. [0] The issue was whether or not introducing new ciphers
not supported by TLS1.3. In 01, we though of adding the code point for
TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
the cipher suites proposed.In case of needs these could still be supported
later by TLS1.3. The consensus seems to not introduce ciphers that would
not be handled by TLS1.3. If the WG decides otherwise, these could still be
added.

[0]
https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007




> This document is just assembling pieces that were already specified
> elsewhere, so it need not contain much detail itself, which is fine.
> That said, I think section 3 should probably state explicitly which
> pieces it uses, instead of a vague reference of being "based on RFC
> 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> computed in the same manner as for ECDHE_PSK key exchange in RFC
> 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> does not cover ECDHE_PSK.)
>

MGLT: I agree we coudl be more explicit, here are the changes I propose. I
believe it address your purpose.

OLD:

Messages and pre-master secret construction in this
document are based on [RFC4279 ].

NEW:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages and premaster secret is
computed as for  the ECDHE_PSK key exchange.


> The premaster_secret structure so used basically ends up putting the
> ECDH output first followed by the static PSK; with the pre-TLS 1.2
> PRF, that would give the ECDH shared secret to md5 and the PSK to
> sha1, which is perhaps another reason to not use these with pre-1.2
> worth mentioning (in addition to the AEAD availability).
>

MGLT: I believe the following text address your concern, however I am
wondering if we are not going beyond the scope of expected considerations.

In addition, it is worth noting that TLS1.0  and
TL1.2  splits the premaster in two parts. The PRF
results of mixing the two pseudorandom streams with distinct hash functions
(MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
authentication, the PSK and pre-master are treated by distinct hash
function with distinct properties. This may introduce vulnerabilities over
the expected security provided by the constructed pre-master. As such
TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.


> The security considerations largely refer to those of the other
> documents providing the pieces that are combined together here;
> those referenced security considerations sections are more than
> adequate here, as this document itself does not really do anything
> particularly novel.  That said, if we are going to reiterate the
> entropy requirement for PSKs inline, we probably ought to also
> reiterate the nonce-reuse considerations for GCM and CCM.  The
> relevant constructions help, but there are still ways to mess up and
> reuse a nonce when doing crypto in parallel, if I remember the
> GCM/TLS document's security considerations correctly.
>

MGLT: I believe the following text address your comments.

 GCM or CCM encryption - even of different clear text - re-using a
nonce with a same key undermines the security of GCM and CCM. As a
result, GCM and CCM MUST only be used with system guaranteeing nonce
uniqueness .


>
> Some other editorial nits follow.
>
> I see we're already discussing "perfect forward secrecy" 

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

[Daniel Migault]

Thanks for the feed backs. I have found two occurrences of perfect forward
secrecy which have been changed to forward secrecy.
Yours,
Daniel


On Thu, May 18, 2017 at 5:51 PM, Viktor Dukhovni 
wrote:

>
> > On May 18, 2017, at 5:30 PM, Eric Rescorla  wrote:
> >
> > I don't much care, but we've moved to "forward secrecy" in TLS 1.3.
>
> That's increasingly the more appropriate term.  Yes, historically
> the word "perfect" was there too, but these days we understand that
> it is only as perfect as the ephemeral key-agreement algorithm,
> which is vulnerable to cryptanalytic advances.
>
> --
> Viktor.
>
> ___
> 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

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

[Daniel Migault]

Hi Simon, 

Thank you for the review. I believe we have addressed your comments in our 
version 04. Please see my comments inline. 

Yours, 
Daniel

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Simon Friedberger
Sent: Thursday, May 04, 2017 5:59 PM
To: i...@ietf.org
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call:  (ECDHE_PSK 
with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to 
Proposed Standard

Nits:

RFC 4279 reference is missing.
MGLT: It seems the reference is mentioned in the current version in the 
Normative reference as well  as in the introduction at line 127,  in section 3 
line 143. In case you meant another reference, please let us know. 



"TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or 
"TLS 1.3 and higher versions"
MGLT: Changed to "TLS 1.3 and higher versions"

On 04/05/17 18:41, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>Security (TLS)'
>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 2017-05-18. 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 defines several new cipher suites for the Transport
>Layer Security (TLS) protocol.  The cipher suites are all based on
>the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>(ECDHE_PSK) key exchange together with the Authenticated Encryption
>with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>provides light and efficient authentication, ECDHE provides perfect
>forward secrecy, and AES-GCM and AES-CCM provides encryption and
>integrity protection.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> ___
> 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

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

Re: [TLS] Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Dan, 

Thank you for your reviews and comments. I believe the following text provides 
more explanation on how the provided cipher suites are negotiated by TLS1.3 as 
well as why point codes defined in the document does not apply to TLS1.3. Feel 
free to let me know if that address your concern and I can publish version 04 
with the text below.

Unlike TLS1.2, TLS1.3 separates authentication and cipher suite negotiation 
 Section 1.2. TLS1.3 supports PSK with ECDHE 
key exchange and the cipher suites TLS_AES_128_GCM_SHA256, 
TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and  TLS_AES_128_CCM_SHA256 
are part of the specification. As a result, TLS 1.3 and higher versions, 
negotiate and support these cipher suites in a different way.

I am not sure we  have to wait for the publication of TLS1.3 as changes on 
TLS1.3 are unlikely to impact the code point assigned. However, we currently 
have TLS1.3 as a normative reference. 

Yours, 
Daniel
-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Monday, May 15, 2017 6:47 AM
To: gen-...@ietf.org
Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org; i...@ietf.org; tls@ietf.org; 
droma...@gmail.com
Subject: Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-ecdhe-psk-aead-??
Reviewer: Dan Romascanu
Review Date: 2017-05-15
IETF LC End Date: 2017-05-18
IESG Telechat date: 2017-05-25

Summary:

This is a straight-forward and clear document that defines several new cipher 
suites for the Transport Layer Security (TLS) protocol version
1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman with 
Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated 
Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. The 
document is well written and I appreciate the effort to clarify in the 
Introduction the context, what was missing, and why the document is necessary. 
The document is Ready, there is one issue about support for TLS version 1.3 and 
higher that may need some text clarification. 

Major issues:

Minor issues:

Section 4 ('Applicable TLS Versions') describes in details how the cipher 
suites defined in the document make use of the authenticated encryption with 
additional data (AEAD) defined in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. 
About TLS 1.3 it just says: 

' TLS 1.3 and above version, negotiate and support these cipher suites in a 
different way.'

This may raise some concerns as 'in a different way' is ambiguous, especially 
compared to the details included for TLS 1.2. Moreover, TLS
1.3 is still work-in-progress, and I believe that this document when approved 
needs to wait for TLS 1.3 to be approved for publication.
Will anything change, or need to be added? Some better clarification text would 
help IMO. 

Nits/editorial comments: 


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

Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

[Daniel Migault]

Hi,

Oops, I missed your email. the version 03 has been submitted. For some reason 
my email address is not in the database, so it has to be confirmed by someone 
else or the secretariat.

Yours,
Daniel

From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Tuesday, May 02, 2017 7:46 AM
To: Daniel Migault <daniel.miga...@ericsson.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

Hi Daniel,

Thank you, please publish version 3 and I'll kick off last call.  You could 
update the TLS version to 20 as well, but that's something that will get fixed 
with the RFC number while in the RFC editor queue.

Best regards,
Kathleen

Sent from my iPhone

On May 1, 2017, at 9:46 PM, Daniel Migault 
<daniel.miga...@ericsson.com<mailto:daniel.miga...@ericsson.com>> wrote:
Hi Kathleen,

Thank you for the review. I have proceeded to the update of my local copy. The 
text is:

"""
The cipher suite numbers listed in the last column are numbers used
for cipher suite interoperability testing and it's suggested that IANA
use these values for assignment.
"""
Other nits have been addressed as well.
If that is fine, I can publish the version 03.
Yours,
Daniel


On Mon, May 1, 2017 at 2:23 PM, Kathleen Moriarty 
<kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:
Hello,

Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02.

In the IANA section, I think it would be a bit more clear to say in
the last column rather than second column wince one might interpret
this listing as having 3 columns.

   The cipher suite numbers listed in the second column are numbers used
   for cipher suite interoperability testing and it's suggested that
   IANA use these values for assignment.

The registry has this reversed with the description as the second
column, which is fine.  I'm just pointing that out as it doesn't
clarify the column for you.

Nits:

Security Considerations section:

   Use of Pre-Shared Keys of limited entropy may allow an active
   attacker attempts to connect to the server and tries different keys.
s/tries/try/

   Other
   example includes the use of a PSK chosen by a human and thus may be
   exposed to dictionary attacks.
s/Other/Another/


--

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

[Daniel Migault]

Hi Kathleen,

Thank you for the review. I have proceeded to the update of my local copy.
The text is:

"""
The cipher suite numbers listed in the last column are numbers used
for cipher suite interoperability testing and it's suggested that IANA
use these values for assignment.
"""

Other nits have been addressed as well.

If that is fine, I can publish the version 03.

Yours,
Daniel


On Mon, May 1, 2017 at 2:23 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello,
>
> Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02.
>
> In the IANA section, I think it would be a bit more clear to say in
> the last column rather than second column wince one might interpret
> this listing as having 3 columns.
>
>The cipher suite numbers listed in the second column are numbers used
>for cipher suite interoperability testing and it's suggested that
>IANA use these values for assignment.
>
> The registry has this reversed with the description as the second
> column, which is fine.  I'm just pointing that out as it doesn't
> clarify the column for you.
>
> Nits:
>
> Security Considerations section:
>
>Use of Pre-Shared Keys of limited entropy may allow an active
>attacker attempts to connect to the server and tries different keys.
> s/tries/try/
>
>Other
>example includes the use of a PSK chosen by a human and thus may be
>exposed to dictionary attacks.
> s/Other/Another/
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> 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

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

[Daniel Migault]

Hi,

I am in favor of adoption of the draft. This is an important issue we need
to address.

Yours,
Daniel

On Wed, Apr 12, 2017 at 3:31 PM, Sean Turner  wrote:

> All,
>
> At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
>
> Cheers,
>
> J
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
> ___
> Lurk mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi Joe,

Thanks for the reminder. I just posted it. Let me know if there is anything
I have to do.

Yours,
Daniel

On Tue, Apr 11, 2017 at 11:21 AM, Joseph Salowey <j...@salowey.net> wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> Hi,
>>
>> Thank you for the review and comments received. Given the discussion our
>> understanding was that the consensus was to remove CCM-256 so that suites
>> defined by the document apply both for TLS1.2 as well as for TLS1.3. The
>> draft available on github [1
>> <https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead>]
>> has been updated as follows:
>>
>>
>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>
>> MGLT: This was a mistake in the IANA section. The cypher suite was
>> correct in the remaining text. However, the current version does not
>> consider anymore CCM-256* which also solves this issue.
>>
>> 2.  Since the security considerations mention passwords (human chosen
>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>
>> MGLT: The issue of human chosen passwords and dictionary attacks has been
>> mentioned in the security consideration with the following text:
>>
>> """
>>Use of Pre-Shared Keys of limited entropy may allow an active
>>attacker attempts to connect to the server and tries different keys.
>>For example, limited entropy may be provided by using short PSK in
>>which case an attacker may perform a brute-force attack.  Other
>>example includes the use of a PSK chosen by a human and thus may be
>>exposed to dictionary attacks.
>> """
>>
>>
>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>> than necessary.
>>
>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>> 1.3 specification.
>>
>> MGLT: CCM-256 has been removed from the specification so that suites can
>> be defined for TLS 1.2 as well as TLS1.3. The following text is considered.
>>
>> """
>>This document defines new cipher suites that provide Pre-Shared Key
>>(PSK) authentication, Perfect Forward Secrecy (PFS), and
>>Authenticated Encryption with Associated Data (AEAD).  The cipher
>>suites are defined for version 1.2 of the Transport Layer Security
>>(TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>[I-D.ietf-tls-tls13].
>> """
>>
>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>> section 4 that states:
>>
>> "TLS 1.3 and above name, negotiate and support a subset of these cipher
>> suites in a different way."  (TLS 1.3 does not support
>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM
>> _8_SHA256)
>>
>> MGLT: As CCM-256 has been removed, we do not have to deal with the
>> situation where TLS1.3 only considers a subset of the suites defined for
>> TLS1.2.
>>
>> The following sentence in section 3 clarifies that codes points are only
>> defined for TLS1.2: “””The assigned code points can only be used for TLS
>> 1.2.”””. The description of the TLS1.3 negotiation has been limited in
>> section 4 to the following sentence: “””TLS 1.3 and above version,
>> negotiate and support these cipher suites in a different way.”””
>>
>> 4. Section 3 should contain a bit more detail about relationship to 4492
>> bis and RFC 4279:
>>
>> Something like the following may be enough.
>>
>> "This messages and pre-master secret construction in this document are
>> based on [RFC4279].  The elliptic curve parameters used in in the
>> Diffie-Hellman parameters are negotiated using extensions defined in
>> [4492-bis]."
>>
>> MGLT: The sentence mentioned above has been added with [4492-bis]
>> mentioned as normative.
>> “””
>> Messages and pre-master secret construction in this document are
>>based on [RFC4279].  The elliptic curve parameters used in in the
>>Diffie-Hellman parameters are negotiated using extensions defined in
>

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi,

Thank you for the review and comments received. Given the discussion our
understanding was that the consensus was to remove CCM-256 so that suites
defined by the document apply both for TLS1.2 as well as for TLS1.3. The
draft available on github [1
]
has been updated as follows:


1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of
SHA384 like the other 256 bit cipher suites? (From Russ Housley)

MGLT: This was a mistake in the IANA section. The cypher suite was correct
in the remaining text. However, the current version does not  consider
anymore CCM-256* which also solves this issue.

2.  Since the security considerations mention passwords (human chosen
secrets) it should mention dictionary attacks. (From Russ Housley)

MGLT: The issue of human chosen passwords and dictionary attacks has been
mentioned in the security consideration with the following text:

"""
   Use of Pre-Shared Keys of limited entropy may allow an active
   attacker attempts to connect to the server and tries different keys.
   For example, limited entropy may be provided by using short PSK in
   which case an attacker may perform a brute-force attack.  Other
   example includes the use of a PSK chosen by a human and thus may be
   exposed to dictionary attacks.
"""


3.  Section 2 and 3 of the document contains more detail about TLS 1.3 than
necessary.

Section 2: This document only defines cipher suites for TLS 1.2, not TLS
1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
1.3 specification.

MGLT: CCM-256 has been removed from the specification so that suites can be
defined for TLS 1.2 as well as TLS1.3. The following text is considered.

"""
   This document defines new cipher suites that provide Pre-Shared Key
   (PSK) authentication, Perfect Forward Secrecy (PFS), and
   Authenticated Encryption with Associated Data (AEAD).  The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
"""

Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
section 4 that states:

"TLS 1.3 and above name, negotiate and support a subset of these cipher
suites in a different way."  (TLS 1.3 does not support
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)

MGLT: As CCM-256 has been removed, we do not have to deal with the
situation where TLS1.3 only considers a subset of the suites defined for
TLS1.2.

The following sentence in section 3 clarifies that codes points are only
defined for TLS1.2: “””The assigned code points can only be used for TLS
1.2.”””. The description of the TLS1.3 negotiation has been limited in
section 4 to the following sentence: “””TLS 1.3 and above version,
negotiate and support these cipher suites in a different way.”””

4. Section 3 should contain a bit more detail about relationship to 4492
bis and RFC 4279:

Something like the following may be enough.

"This messages and pre-master secret construction in this document are
based on [RFC4279].  The elliptic curve parameters used in in the
Diffie-Hellman parameters are negotiated using extensions defined in
[4492-bis]."

MGLT: The sentence mentioned above has been added with [4492-bis] mentioned
as normative.
“””
Messages and pre-master secret construction in this document are
   based on [RFC4279].  The elliptic curve parameters used in in the
   Diffie-Hellman parameters are negotiated using extensions defined in
   [I-D.ietf-tls-rfc4492bis].
“””

[1]
https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead

Yours,
Daniel and John


On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  wrote:

> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>
> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>
> 2.  Since the security considerations mention passwords (human chosen
> secrets) it should mention dictionary attacks. (From Russ Housley)
>
> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
> than necessary.
>
> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
> 1.3 specification.
>
> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
> section 4 that states:
>
> "TLS 1.3 and above name, negotiate and support a subset of these cipher
> suites in a different way."  (TLS 1.3 does not support 
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384
> and TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
>
> 4. Section 3 should contain a bit more detail about relationship to 4492
> bis and RFC 4279:
>
> Something like 

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Daniel Migault]

I have a small preference for TLS 1.3.

On Tue, Nov 22, 2016 at 10:04 AM, Scott Schmit  wrote:

> On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote:
> > At IETF 97, the chairs lead a discussion to resolve whether the WG
> should rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to
> not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this
> decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.
>
> I find it compelling that if we lived in an alternate universe where we
> had SSL 1996, TLS 1999, and a recently-published TLS 2006 or TLS 2008,
> there would have been a lot less inertia about switching to a later
> version.  I find is very optimistic given our history that we could
> manage two TLS versions in a year.  If that ever happened, though, we
> could do 2019.1 (as an increment) or 2019.11 (for the month).
>
> Barring that, I'd prefer TLS 4, since that gets us out of the version
> confusion swamp.  It would seem that almost nobody outside the security
> community understands the distinction between SSL and TLS; so if we call
> it TLS 4, we'll probably see it referred to as SSLv4.  And that wouldn't
> be horrible.  If we call it TLS 2 or TLS 2.0, some might refer to it as
> SSLv2.  That would obviously be very bad.
>
> While it's nice to able to look up information about TLS 1.3 drafts,
> most of that information is going to be inaccurate anyway, so I don't
> see that as a compelling reason to stick to it.  Granted, you have
> specific buzz for "TLS 1.3 is going to really improve things" but that's
> fairly easy to translate to "the new version of TLS is going to really
> improve things".
>
> The distinction between 2 vs 2.0 seems pretty minor.  SSLv2 is 2.0 and
> SSLv3 is 3.0, but few write it that way.
>
> Thus my ranked preference would be:
>
> TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0
>
> But if I'm limited to a top choice from the list, then "Rebrand TLS 4"
>
> --
> Scott Schmit
>
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

I removed all these recommendations on 128/256 security. I believe this
address this thread.

I also believe a profile document would be useful and detail these details.
Do you have any opinion about such a document ?

Tank you for the feed backs!

Yours,
Daniel

On Tue, Nov 8, 2016 at 7:24 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> On 8 November 2016 at 21:08, Daniel Migault <daniel.miga...@ericsson.com>
> wrote:
> > TLS enable curve negotiation but not for code point. This makes
> restrictions
> > on code points hard to implement.  As a result Endpoints MAY treat
> > negotiation of key sizes smaller than the lower limits as a connection
> error
> > of type insufficient_security(71) for TLS 1.2 and TLS 1.3.
>
> I really had a hard time parsing this.  You don't connect this to
> Diffie-Hellman at all, but I think that is what you are talking about.
> But if your point is that this is an ECDHE-specific draft, then you
> don't need to say anything at all.
>
> nit "TLS enables"
>
> ___
> 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

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

done.

Thanks for the review!

Yours

Daniel

On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:

> On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> > Hi,
> >
> > The current draft is only considering TLS1.2. TLS1.3 is only mentioned
> for
> > advocating AEAD.
> >
> > Do you think we should add text that details how to proceed with TLS1.3 ?
> > If so what do you think of the following text ?
>
> That is, I think the dependency on TLS 1.3 should be downgraded to
> informative (unless that has already been done).
>
> >
> > Yours,
> > Daniel
> >
> >The assigned code points are only expected to be used for TLS1.2.
> >TLS1.3 does not follow the same name convention.  Instead TLS1.3
> >cipher suites are designated according to the AEAD suite as well as
> >the hash function used.  The current combination of AEAD algorithms
> >and Hash fucntion are already defined in TLS.1.3 so there is no need
> >to add additional cipher suites for TLS1.3.
>
> Seems reasonable.
>
> >Instead, in order to used the following ECDHE_PSK authentication
> >method.  TLS1.3 uses a combination of the "key_share" and
> >"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
> >extension sets its mode to psk_dhe_ke.  The "key_share" extention
> >contains a KeyShareEntry structure that carries the ECDHE parameters.
> >
>
> I think 'used the following' -> 'use the' and first period should be
> comma.
>
>
> -Ilari
>
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

If I understand correctly, you recommend something that is of the flavor in
the security recommendation section:

TLS enable curve negotiation but not for code point. This makes
restrictions on code points hard to implement.  As a result Endpoints MAY
treat negotiation of key sizes smaller than the lower limits as a
connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

If that is correct I will propose some better text explaining why we can
hardly provide some better text, including the one provided by HTTP2.

Yours,
Daniel


On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos <n...@redhat.com>
wrote:

> On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:
>
> > Regarding Niko, my understanding is that the WG preferred not to have
> > the definition of profiles in this document. I am not sure you wanted
> > the text to be removed as MUST NOT was to normative or if you would
> > like no recommendation at all. The reason I would rather advocate for
> > recommendation is that ECDHE does not specify an algorithm with a
> > specific security. As a result, I would rather provide some guide
> > lines to avoid weak authentication being used with high long AES
> > keys.
>
> That's a valid concern, but TLS doesn't have the notion of a security
> level, and I am not sure that you can easily introduce it with a
> ciphersuite point assignment rfc. With TLS you can easily use AES-256
> with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
> certificate of 32-bits. One can use your draft with a 8-bit PSK, and
> still be insecure despite the fact that you force a 256-bit curve or
> better. When trying to ensure a consistent level you may likely need to
> adjust the finished message size as well.
>
> Nevertheless, I think to cover your goal, a security considerations
> addition that makes apparent that in addition to the ciphersuite
> parameters, the TLS protocol finished message size, the elliptic curves
> used, and the size of the selected key define the security level of the
> session.
>
> regards,
> Nikos
>
> ___
> 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

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi,

The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
advocating AEAD.

Do you think we should add text that details how to proceed with TLS1.3 ?
If so what do you think of the following text ?

Comments are welcome!


Yours,
Daniel

   The assigned code points are only expected to be used for TLS1.2.
   TLS1.3 does not follow the same name convention.  Instead TLS1.3
   cipher suites are designated according to the AEAD suite as well as
   the hash function used.  The current combination of AEAD algorithms
   and Hash fucntion are already defined in TLS.1.3 so there is no need
   to add additional cipher suites for TLS1.3.

   Instead, in order to used the following ECDHE_PSK authentication
   method.  TLS1.3 uses a combination of the "key_share" and
   "psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
   extension sets its mode to psk_dhe_ke.  The "key_share" extention
   contains a KeyShareEntry structure that carries the ECDHE parameters.



On Tue, Oct 18, 2016 at 12:31 PM, Ilari Liusvaara 
wrote:

> On Tue, Oct 18, 2016 at 04:22:59PM +, Xiaoyin Liu wrote:
> > Why does this draft normatively depend on TLS 1.3, even if the
> > cipher suites defined in this draft use the old syntax, which
> > TLS 1.3 no longer uses?
>
> I don't see any reason why it would normatively depend.
>
> If it claims to be so, IMO that is a mistake and such reference should
> be dropped (TLS 1.3 won't be able to use these anyway), or made in-
> formative, in case the text wants to make a passing reference to TLS
> 1.3.
>
>
> -Ilari
>
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

Hi,

My understanding is that the updated version should not introduce any
profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.miga...@ericsson.com
> wrote:

> Hi,
>
> I am not very clear on how to update the text of the draft. The problem
> seems to me that code point restriction are hard to implement. As a result,
> the session is aborted with - insufficient_security(71) or equivalent -
> when the code point does not match the security strength. I am encline to
> think that we should also provide some profiles that achieve 128/256 bit
> security. These profiles may be described in this document or in another
> document more related to cryptographic recommendation. What would be the
> most appropriated way to move forward ?
>
> BR,
> Daniel
>
>
>
> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson <john.matts...@ericsson.com>
> wrote:
>
>> Hi Dan, Sean, Nikos,
>>
>> First, let me state that I think requiring 128-bit key management for
>> AES-128 is quite reasonable.
>>
>> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
>> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
>> smaller than the lower limits as a connection error (Section 5.4.1
>> <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type
>> INADEQUATE_SECURITY."
>>
>>
>> I think this is a question for TLS in general,
>> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
>> with insufficient security as an error.
>>
>> I think the real problem here are TLS libraries supporting 1024 MODP and
>> 160 ECC at all, support for these should have been removed before 2010.
>> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
>> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
>> than bundling it into a code-point assignment RFC. (My current plans for
>> the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
>> support of anything weaker than 2048 MODP and 255-bit ECC).
>>
>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl
>> BKvZs0BOQ
>>
>>
>>
>> Cheers,
>> John
>>
>>
>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-boun...@ietf.org
>> on
>> behalf of dhark...@lounge.org> wrote:
>>
>> >
>> >  I'm glad I have to opportunity to make you happy Sean :-)
>> >
>> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> >> I think I can take this bit:
>> >>
>> >> On Jul 10, 2016, at 06:51, Peter Dettman
>> >><peter.dett...@bouncycastle.org>
>> >> wrote:
>> >>>
>> >>> I'm also curious whether there is a precedent in other RFCs for an
>> >>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>> >>
>> >> I'd be happy to be wrong here. but to my knowledge no there's not been
>> >> an explicit minimum for curve bits.  There have however been similar
>> (at
>> >> least in my non-cryptographer mind) for RSA key sizes so if we wanted
>> to
>> >> define an explicit minimum curve bits then we could.
>> >
>> >  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>> >the curves used provide commensurate strength with the ciphersuite
>> >negotiated. Section 10, "Implementation Considerations", says:
>> >
>> >   It is RECOMMENDED that implementations take note of the strength
>> >   estimates of particular groups and to select a ciphersuite providing
>> >   commensurate security with its hash and encryption algorithms.  A
>> >   ciphersuite whose encryption algorithm has a keylength less than the
>> >   strength estimate, or whose hash algorithm has a blocksize that is
>> >   less than twice the strength estimate SHOULD NOT be used.
>> >
>> >  And I would like to take this opportunity to remind everyone that
>> >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
>> >to dictionary attack and the former is not.
>> >
>> >  regards,
>> >
>> >  Dan.
>> >
>> >
>> >
>> >___
>> >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
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi,

We are discussing in the TLS wg assignment points for TLS PSK
authentication. We would like to understand if there is a specific interest
of the IoT community for the following suites.

TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};

Additional question might be whether AES_256_CCM_8_SHA384 is of interest
for an IoT use case.

Any feed back is appreciated. please provide them by the end of the week!

BR,
Daniel



On Mon, Oct 17, 2016 at 12:08 PM, Russ Housley <hous...@vigilsec.com> wrote:

> I would like to see these included:
>
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
>
>
> I am fine with including these as well if someone wants to use them:
>
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};
>
>
> I do not really see a reason to include the ones with the shorter MAC:
>
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
>
>
> Russ
>
>
> On Oct 17, 2016, at 12:03 PM, Daniel Migault <daniel.miga...@ericsson.com>
> wrote:
>
> Hi,
>
> I am not clear what the consensus is for the following points. Is there
> any consensus for requesting the following ones?
>
> BR,
> Daniel
>
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};
>
>
>
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <martin.thom...@gmail.com>
> wrote:
>
>> I'm mainly just looking to economize on different configurations.
>>
>> On 9 October 2016 at 16:32, John Mattsson <john.matts...@ericsson.com>
>> wrote:
>> > Hi Martin,
>> >
>> >
>> > AES_256_CCM_8 was not in the first versions of the draft but added later
>> > after request from IoT people (probably afraid of quantum computers).
>> >
>> >
>> > While I think it makes very much sense to have short tags in wireless
>> > radio, I do not know how large need there is for AES-256 in IoT for
>> > constrained devices, or how large the need would be to truncate the tag
>> in
>> > these cases.
>> >
>> >
>> > My current understanding is that Grover’s algorithm may never be more
>> > cost-effective than a cluster of classical computers, and that quantum
>> > computers therefore likely do not affect the lifetime of AES-128.
>> >
>> >
>> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or
>> not.
>> > We should not give the impression that AES-256 is needed for practical
>> > resistance to quantum computers anytime soon, it is however a
>> requirement
>> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
>> > like the best choices in most cases.
>> >
>> >
>> > Cheers,
>> > John
>> >
>> >
>> >
>> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <
>> tls-boun...@ietf.org
>> > on behalf of martin.thom...@gmail.com> wrote:
>> >
>> >>Looking at those emails, I am prompted to wonder if anyone can justify
>> >>the existence of a ciphersuite with a double-sized key and half-sized
>> >>authentication tag.  RFC 6655 doesn't really explain how that is a
>> >>useful thing.
>> >>
>> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <n...@redhat.com>
>> >>wrote:
>> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>> >>>> All,
>> >>>>
>> >>>> We've received a request for early IANA assignments for the 6 cipher
>> >>>> suites listed in https://datatracker.ietf.org/d
>> oc/draft-ietf-tls-ecdh
>> >>>> e-psk-aead/.  Please respond before August 23rd if you have concerns
>> >>>> about early code point assignment for these cipher suites.
>> >>>
>> >>> I have previously raised an issue [0] on these ciphersuites. The same
>> >>> requirement was note

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

Hi,

I am not very clear on how to update the text of the draft. The problem
seems to me that code point restriction are hard to implement. As a result,
the session is aborted with - insufficient_security(71) or equivalent -
when the code point does not match the security strength. I am encline to
think that we should also provide some profiles that achieve 128/256 bit
security. These profiles may be described in this document or in another
document more related to cryptographic recommendation. What would be the
most appropriated way to move forward ?

BR,
Daniel



On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson 
wrote:

> Hi Dan, Sean, Nikos,
>
> First, let me state that I think requiring 128-bit key management for
> AES-128 is quite reasonable.
>
> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
> smaller than the lower limits as a connection error (Section 5.4.1
> ) of type
> INADEQUATE_SECURITY."
>
>
> I think this is a question for TLS in general,
> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
> as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
> with insufficient security as an error.
>
> I think the real problem here are TLS libraries supporting 1024 MODP and
> 160 ECC at all, support for these should have been removed before 2010.
> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
> than bundling it into a code-point assignment RFC. (My current plans for
> the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
> support of anything weaker than 2048 MODP and 255-bit ECC).
>
> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>
>
>
> Cheers,
> John
>
>
> On 11/07/16 22:26, "TLS on behalf of Dan Harkins"  behalf of dhark...@lounge.org> wrote:
>
> >
> >  I'm glad I have to opportunity to make you happy Sean :-)
> >
> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> >> I think I can take this bit:
> >>
> >> On Jul 10, 2016, at 06:51, Peter Dettman
> >>
> >> wrote:
> >>>
> >>> I'm also curious whether there is a precedent in other RFCs for an
> >>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
> >>
> >> I'd be happy to be wrong here. but to my knowledge no there's not been
> >> an explicit minimum for curve bits.  There have however been similar (at
> >> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
> >> define an explicit minimum curve bits then we could.
> >
> >  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
> >the curves used provide commensurate strength with the ciphersuite
> >negotiated. Section 10, "Implementation Considerations", says:
> >
> >   It is RECOMMENDED that implementations take note of the strength
> >   estimates of particular groups and to select a ciphersuite providing
> >   commensurate security with its hash and encryption algorithms.  A
> >   ciphersuite whose encryption algorithm has a keylength less than the
> >   strength estimate, or whose hash algorithm has a blocksize that is
> >   less than twice the strength estimate SHOULD NOT be used.
> >
> >  And I would like to take this opportunity to remind everyone that
> >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
> >to dictionary attack and the former is not.
> >
> >  regards,
> >
> >  Dan.
> >
> >
> >
> >___
> >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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi,

I am not clear what the consensus is for the following points. Is there any
consensus for requesting the following ones?

BR,
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};



On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson 
wrote:

> I'm mainly just looking to economize on different configurations.
>
> On 9 October 2016 at 16:32, John Mattsson 
> wrote:
> > Hi Martin,
> >
> >
> > AES_256_CCM_8 was not in the first versions of the draft but added later
> > after request from IoT people (probably afraid of quantum computers).
> >
> >
> > While I think it makes very much sense to have short tags in wireless
> > radio, I do not know how large need there is for AES-256 in IoT for
> > constrained devices, or how large the need would be to truncate the tag
> in
> > these cases.
> >
> >
> > My current understanding is that Grover’s algorithm may never be more
> > cost-effective than a cluster of classical computers, and that quantum
> > computers therefore likely do not affect the lifetime of AES-128.
> >
> >
> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or not.
> > We should not give the impression that AES-256 is needed for practical
> > resistance to quantum computers anytime soon, it is however a requirement
> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
> > like the best choices in most cases.
> >
> >
> > Cheers,
> > John
> >
> >
> >
> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <
> tls-boun...@ietf.org
> > on behalf of martin.thom...@gmail.com> wrote:
> >
> >>Looking at those emails, I am prompted to wonder if anyone can justify
> >>the existence of a ciphersuite with a double-sized key and half-sized
> >>authentication tag.  RFC 6655 doesn't really explain how that is a
> >>useful thing.
> >>
> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos 
> >>wrote:
> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>  All,
> 
>  We've received a request for early IANA assignments for the 6 cipher
>  suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
>  e-psk-aead/.  Please respond before August 23rd if you have concerns
>  about early code point assignment for these cipher suites.
> >>>
> >>> I have previously raised an issue [0] on these ciphersuites. The same
> >>> requirement was noted also by Peter Dettman as something special in
> >>> [1]. However, there has been no reaction from the authors (now in CC).
> >>>
> >>> regards,
> >>> Nikos
> >>>
> >>> [0].
> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
> >>> [1].
> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
> >>>
> >>> ___
> >>> 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
> >
>
> ___
> 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

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Daniel Migault]

I support the adoption of the draft.

On Mon, Apr 25, 2016 at 1:53 PM, Salz, Rich  wrote:

> I support adoption.
>
> --
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
>
>
> ___
> 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

Re: [TLS] New Version Notification for draft-cairns-tls-session-key-interface-01.txt

[Daniel Migault]

Hi, 

Please find our new version from of the Session Key Interface for TLS and DTLS.

The main motivation for this interface is that the private key is centralized 
in a Key Server instead of being distributed and copied among the Edge Servers. 
All cryptographic operation are performed by the Key Server and the Edge Server 
uses this interface.   

Feel free to comment the draft but here are some our concerns and we would like 
to know your opinion:

QUESTION 1) An interaction occurs when RSA or ephemeral Diffie Hellman 
(DHE_RSA, ECDHE_RSA or ECDHE_ECDSA) key agreement . In your opinion, should we 
consider RSA?

QUESTION 2) When Diffie Hellman is used, to build the signature, the Edge 
Server provides all parameters to the key Server, and the Key Server hashes and 
signs. An alternative would be the Edge Server hashes and requests the Key 
Server to sign it. We believe the first alternative is more secure, but the 
second generates less load on the network . Do you have any opinion regarding 
these two alternatives.

BR, 
Daniel

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, October 19, 2015 7:59 PM
To: Kelsey Cairns; John Mattsson; Daniel Migault; Robert Skog
Subject: New Version Notification for 
draft-cairns-tls-session-key-interface-01.txt


A new version of I-D, draft-cairns-tls-session-key-interface-01.txt
has been successfully submitted by John Mattsson and posted to the IETF 
repository.

Name:   draft-cairns-tls-session-key-interface
Revision:   01
Title:  Session Key Interface (SKI) for TLS and DTLS
Document date:  2015-10-19
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-cairns-tls-session-key-interface-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-cairns-tls-session-key-interface/
Htmlized:   
https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-cairns-tls-session-key-interface-01

Abstract:
   This document describes a session key interface that can be used for
   TLS and DTLS.  The Heartbleed attack has clearly illustrated the
   security problems with storing private keys in the memory of the TLS
   server.  Hardware Security Modules (HSM) offer better protection but
   are inflexible, especially as more (D)TLS servers are running on
   virtualized servers in data centers.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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