Subject: [secdir] Secdir review of draft-ietf-mpls-tp-oam-id-mib-08

From: Tina TSOU <[email-masked]>
Date: Tue, 1 Sep 2015 14:09:55 +0000

Dear 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.

The document seems ready to go. I only found these minor nits:

The title of this draft indicates mib for MPLS-TP OAM ID but in the body MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used interchangeable. Besides, I notice that the names for the objects all start with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is not aligned with the title of this draft. A bit confused. Could the authors provide any clarification on this? A general suggestion is to make alignment throughout the document, including the title of the draft.

* Abstract:

> it describes Operations, Administration, and Management (OAM)
> identifiers related managed objects for Multiprotocol Label Switching
> (MPLS) and MPLS based Transport Profile (TP).

I find this sentence hard to parse. Maybe s/related managed objects/related to managed objects/ ?

* Section 1, page 3:
> MPLS LSP(Label

There's a missing space.

* Section 5.1, page 4:

> The mplsOamIdMegTable is used to manage one or more Maintenance
> Entities (MEs) that belongs

s/belongs/belong/

* Section 6, copy&paste mistake

-- Source MEP id is derived from the IP compatible MPLS LSP
       mplsOamIdMeSinkMepIndex           = 0,

The description in the note should be sink MEP. There is already another line to describe source MEP.

* Page 15:

> BFD

This is the first and only instance of BFD. Please expand. (and maybe reference RFC5880)?

* Page 17:

"p2p" and "P2P" first used here. should probably be expanded.

Thank you,
Tina

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Tue, 1 Sep 2015 20:58:38 -0700

Thanks for your comments Tina, will address and publish the new version 09
soon.

-Venkat,

On Tue, Sep 1, 2015 at 7:09 AM, Tina TSOU <[email-masked]>
wrote:

> Dear 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.
>
> The title of this draft indicates mib for MPLS-TP OAM ID but in the body
> MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS
> tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used
> interchangeable. Besides, I notice that the names for the objects all start
> with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is
> not aligned with the title of this draft. A bit confused. Could the authors
> provide any clarification on this? A general suggestion is to make
> alignment throughout the document, including the title of the draft.
>
>
>
> * Abstract:
>
>
>

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Tue, 1 Sep 2015 23:47:06 -0700

Tina,

We have published the new version 09, please go through the diff, if you
have any further comments, please let us know.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-id-mib-09.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-09
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-09

>>interchangeable. Besides, I notice that the names for the objects all
start with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then
it is not aligned with the title of this draft. A bit confused. Could the
authors provide >>any clarification on this? A general suggestion is to
make alignment throughout the document, including the title of the draft.

As Loa suggested, we have included MPLS-TP (as we do this work as part of
MPLS-TP) in the title but this draft actually describes the managed object
for both MPLS and MPLS-TP tunnel identifiers.

-Venkat.

---

From: Tina TSOU <[email-masked]>
Date: Mon, 7 Sep 2015 01:23:15 +0000

Dear Venkat,

Thank you for your prompt reply.

I reviewed -09, it solves my previous comments.

Thank you,
Tina

From: Venkatesan Mahalingam [mailto:[email-masked]]
Sent: Wednesday, September 02, 2015 2:47 PM
To: Tina TSOU
Cc: [email-masked]; [email-masked]; The IESG
Subject: Re: Secdir review of draft-ietf-mpls-tp-oam-id-mib-08

Tina,

We have published the new version 09, please go through the diff, if you have any further comments, please let us know.

URL:            https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-id-mib-09.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-09
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-09

>>The title of this draft indicates mib for MPLS-TP OAM ID but in the body MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used >>interchangeable. Besides, I notice that the names for the objects all start with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is not aligned with the title of this draft. A bit confused. Could the authors provide >>any clarification on this? A general suggestion is to make alignment throughout the document, including the title of the draft.

As Loa suggested, we have included MPLS-TP (as we do this work as part of MPLS-TP) in the title but this draft actually describes the managed object for both MPLS and MPLS-TP tunnel identifiers.

-Venkat.

On Tue, Sep 1, 2015 at 8:58 PM, Venkatesan Mahalingam <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for your comments Tina, will address and publish the new version 09 soon.

-Venkat,

On Tue, Sep 1, 2015 at 7:09 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

There's a missing space.

s/belongs/belong/

* Page 17:

Thank you,
Tina

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Sep 2015 17:58:39 -0700

Hi Magnus,

Thank you for your review and comments.  Please see in-line.

At 9:26 PM -0700 8/31/15, Magnus Nyström wrote:

>  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 memo provides fundamental data structure 
> definitions and procedural rules for providing 
> auxiliary information to public service 
> answering points (PSAPs) when emergency calls 
> are being made.
>
>
>  This reads as an important memo and has been at 
> least five years in the making. I don't find 
> the Security (and Privacy) Considerations 
> section lacking per se, but do have these 
> questions:
>
>  - Why require HTTPS for the reference case but 
> not the value case (I can understand why you 
> don't require it for the value case, but 
> couldn't it be a choice for the PSAP also in 
> the reference case? This would also seem to 
> simplify during an introductory phase when a 
> wide-spread PKI solution is not yet in place.)?

I'm very surprised that a security area person is 
asking why we don't make TLS optional!  It's a 
valid question, of course, just surprising in 
this context.  Because of the limited scope of 
the document, specifically emergency services, 
and given that the dereferencing entities will be 
PSAPs and other responders that have upgraded to 
support next-generation, we felt that it was 
reasonable to require the use of TLS and 
client-side certificates for dereferencing.

>  - When HTTPS is required, I assume the PSAP 
> needs a client certificate - i.e., that the 
> mutual auth option of TLS is being used, 
> perhaps this needs to be clarified?

Yes, good point.  I added clarifying text in response to Ben's comments.

>  - Was there any discussion around any MTI TLS cipher suites?

No, this was never discussed as far as I can recall.

>  - I assume there's not only a privacy issue but 
> also a potential spoofing issue - the PSAPs 
> don't want to be overly susceptible to spoofed 
> calls (although they rather err on the side of 
> safety, of course. Thus, should integrity of 
> infomation in the direct case be considered? 
> I.e., by n/w or service providers in the path 
> to the PSAP vouching for the information?

You're absolutely correct that PSAPs are 
concerned about spoofed (and other false) calls 
but will generally err by taking a call and 
asking the caller for information.  In general, 
PSAPs prefer information that comes from known 
and trusted providers (the major carriers).  Are 
you suggesting a mechanism by which providers 
verify the information provided by the device? 
For location information, there are discussions 
in other SDOs about sanity-checking 
device-provided information (location or Wi-Fi 
APs) against network-known information (macro 
cell to which the device is associated).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
In a sense, when we started Virgin Atlantic, I was trying to create
an airline for myself. If you try to build the perfect airline for
yourself, it will be appreciated by others. --Richard Branson, 1996.

---

From: Magnus Nyström <[email-masked]>
Date: Tue, 15 Sep 2015 18:39:53 -0700

Hi Randall,
Yes, I guess it may be surprising ... but I was thinking more about getting
this effort implemented in an expedited fashion rather than potentially
delaying due to the potential issues (also pointed out in the draft) around
getting the necessary trust anchors in place between PSAPs and service
providers enabling the mutual authentication.

It may be good to say something about MTI suites - I would suggest
mandating support for a set of suites that offers PFS and avoids CBC, e.g.,
something like:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

I would also suggest mandating TLS 1.2 (or later) for a new application
like this.
On the last point, yes, if the service provider is in a possession to vouch
for or sanity-check then that could help introduce reliability.

Best,

On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <[email-masked]>
wrote:

>>  This memo provides fundamental data structure definitions and procedural
>> rules for providing auxiliary information to public service answering
>> points (PSAPs) when emergency calls are being made.
>>
>>
>>  This reads as an important memo and has been at least five years in the
>> making. I don't find the Security (and Privacy) Considerations section
>> lacking per se, but do have these questions:
>>
>>  - Why require HTTPS for the reference case but not the value case (I can
>> understand why you don't require it for the value case, but couldn't it be
>> a choice for the PSAP also in the reference case? This would also seem to
>> simplify during an introductory phase when a wide-spread PKI solution is
>> not yet in place.)?
>>
>
> I'm very surprised that a security area person is asking why we don't make
> TLS optional!  It's a valid question, of course, just surprising in this
> context.  Because of the limited scope of the document, specifically
> emergency services, and given that the dereferencing entities will be PSAPs
> and other responders that have upgraded to support next-generation, we felt
> that it was reasonable to require the use of TLS and client-side
> certificates for dereferencing.
>
>  - When HTTPS is required, I assume the PSAP needs a client certificate -
>> i.e., that the mutual auth option of TLS is being used, perhaps this needs
>> to be clarified?
>>
>
>  - I assume there's not only a privacy issue but also a potential spoofing
>> issue - the PSAPs don't want to be overly susceptible to spoofed calls
>> (although they rather err on the side of safety, of course. Thus, should
>> integrity of infomation in the direct case be considered? I.e., by n/w or
>> service providers in the path to the PSAP vouching for the information?
>>
>
> You're absolutely correct that PSAPs are concerned about spoofed (and
> other false) calls but will generally err by taking a call and asking the
> caller for information.  In general, PSAPs prefer information that comes
> from known and trusted providers (the major carriers).  Are you suggesting
> a mechanism by which providers verify the information provided by the
> device? For location information, there are discussions in other SDOs about
> sanity-checking device-provided information (location or Wi-Fi APs) against
> network-known information (macro cell to which the device is associated).
>
> --
> Randall Gellens

-- 
-- Magnus

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Sep 2015 19:06:49 -0700

Hi Magnus,

I think we can mandate TLS 1.2 or later without 
any problem, and I can add that to the text that 
mandates HTTPS.  I don't think I can add MTI 
cypher suites at this stage, but I think it would 
be OK to add text such as "it is RECOMMENDED to 
use only suites that offer Perfect Forward 
Secrecy (PFS) and avoid Cipher Block Chaining 
(CBC)", with your list of suites as an example. 
What do you think?  If we go this way, I'd 
probably need to also add an informational 
reference or two; what do you suggest?

At 6:39 PM -0700 9/15/15, Magnus Nyström wrote:

>  Hi Randall,
>  Yes, I guess it may be surprising ... but I was 
> thinking more about getting this effort 
> implemented in an expedited fashion rather than 
> potentially delaying due to the potential 
> issues (also pointed out in the draft) around 
> getting the necessary trust anchors in place 
> between PSAPs and service providers enabling 
> the mutual authentication.
>
>  It may be good to say something about MTI 
> suites - I would suggest mandating support for 
> a set of suites that offers PFS and avoids CBC, 
> e.g., something like:
>
>  I would also suggest mandating TLS 1.2 (or 
> later) for a new application like this.
>  On the last point, yes, if the service provider 
> is in a possession to vouch for or sanity-check 
> then that could help introduce reliability.
>
>  Best,
>
>
>  On Tue, Sep 15, 2015 at 5:58 PM, Randall 
> Gellens 
> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
>  Hi Magnus,
>
>   This reads as an important memo and has been 
> at least five years in the making. I don't find 
>  I'm very surprised that a security area person 
> is asking why we don't make TLS optional!  It's 
> a valid question, of course, just surprising in 
> and given that the dereferencing entities will 
> be PSAPs and other responders that have 
> upgraded to support next-generation, we felt 
> that it was reasonable to require the use of 
> TLS and client-side certificates for 
> dereferencing.
>
>   - I assume there's not only a privacy issue 
> but also a potential spoofing issue - the PSAPs 
> and trusted providers (the major carriers). 
> Are you suggesting a mechanism by which 
> providers verify the information provided by 
> the device? For location information, there are 
> discussions in other SDOs about sanity-checking 

-------------- Randomly selected tag: ---------------
All we're seeing is the negative side of nuclear war.
    --Barry Goldwater

---

From: Magnus Nyström <[email-masked]>
Date: Tue, 15 Sep 2015 20:09:03 -0700

Yes, at least mandating TLS 1.2 or higher and recommending as per above
seems reasonable.
The references for the GCM suites would be RFC 5288 and RFC 5289.

Thanks!

On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens <[email-masked]>
wrote:

> Hi Magnus,
>
> I think we can mandate TLS 1.2 or later without any problem, and I can add
> that to the text that mandates HTTPS.  I don't think I can add MTI cypher
> suites at this stage, but I think it would be OK to add text such as "it is
> RECOMMENDED to use only suites that offer Perfect Forward Secrecy (PFS) and
> avoid Cipher Block Chaining (CBC)", with your list of suites as an example.
> What do you think?  If we go this way, I'd probably need to also add an
> informational reference or two; what do you suggest?
>
>>  Yes, I guess it may be surprising ... but I was thinking more about
>> getting this effort implemented in an expedited fashion rather than
>> potentially delaying due to the potential issues (also pointed out in the
>> draft) around getting the necessary trust anchors in place between PSAPs
>> and service providers enabling the mutual authentication.
>>
>>  On the last point, yes, if the service provider is in a possession to
>> vouch for or sanity-check then that could help introduce reliability.
>>
>>  Best,
>>
>>
>>  On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <<mailto:
>> [email-masked]>[email-masked]> wrote:
>>
>>  Hi Magnus,
>>
>>   This memo provides fundamental data structure definitions and
>> procedural rules for providing auxiliary information to public service
>> answering points (PSAPs) when emergency calls are being made.
>>
>>
>>   - Why require HTTPS for the reference case but not the value case (I
>> can understand why you don't require it for the value case, but couldn't it
>> be a choice for the PSAP also in the reference case? This would also seem
>> to simplify during an introductory phase when a wide-spread PKI solution is
>> not yet in place.)?
>>
>>
>>  I'm very surprised that a security area person is asking why we don't
>> make TLS optional!  It's a valid question, of course, just surprising in
>> this context.  Because of the limited scope of the document, specifically
>>   - When HTTPS is required, I assume the PSAP needs a client certificate
>> - i.e., that the mutual auth option of TLS is being used, perhaps this
>> needs to be clarified?
>>
>>
>>   - I assume there's not only a privacy issue but also a potential
>> spoofing issue - the PSAPs don't want to be overly susceptible to spoofed
>> calls (although they rather err on the side of safety, of course. Thus,
>> should integrity of infomation in the direct case be considered? I.e., by
>> n/w or service providers in the path to the PSAP vouching for the
>> information?
>>
>>
>> from known and trusted providers (the major carriers). Are you suggesting a
>> mechanism by which providers verify the information provided by the device?
>> For location information, there are discussions in other SDOs about

-- 
-- Magnus

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Sep 2015 21:21:14 -0700

I've made these changes and included the two references.  Thanks very much.

At 8:09 PM -0700 9/15/15, Magnus Nyström wrote:

>>>   Yes, good point.  I added clarifying text in response to Ben's comments

-------------- Randomly selected tag: ---------------
This fortune intentionally not included.

---

From: [email-masked]
Date: Wed, 16 Sep 2015 07:38:03 +0000

> The references for the GCM suites would be RFC 5288 and RFC 5289.

BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not correct for this context.

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Sep 2015 11:55:41 +0100

I think BCP195 does the job for us.

-----Original Message-----
From: secdir [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 16 September 2015 09:38
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data

On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nyström wrote:
> Yes, at least mandating TLS 1.2 or higher and recommending as per
> above seems reasonable.

S.

> > I think we can mandate TLS 1.2 or later without any problem, and I
> > can add that to the text that mandates HTTPS.  I don't think I can
> > add MTI cypher suites at this stage, but I think it would be OK to
> > add text such as "it is RECOMMENDED to use only suites that offer
> > Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC)", with your list of suites as an example.
> > What do you think?  If we go this way, I'd probably need to also add
> > an informational reference or two; what do you suggest?
> >
> >>  Yes, I guess it may be surprising ... but I was thinking more
> >> about getting this effort implemented in an expedited fashion
> >> rather than potentially delaying due to the potential issues (also
> >> pointed out in the
> >> draft) around getting the necessary trust anchors in place between
> >> PSAPs and service providers enabling the mutual authentication.
> >>
> >> mandating support for a set of suites that offers PFS and avoids
> >> CBC, e.g., something like:
> >>
> >>  I would also suggest mandating TLS 1.2 (or later) for a new
> >> application like this.
> >>  On the last point, yes, if the service provider is in a possession
> >> to vouch for or sanity-check then that could help introduce reliability.
> >>
> >>  Best,
> >>
> >>
> >>   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.
> >>
> >> procedural rules for providing auxiliary information to public
> >> service answering points (PSAPs) when emergency calls are being made.
> >>
> >>
> >>   This reads as an important memo and has been at least five years
> >> in the making. I don't find the Security (and Privacy)
> >> Considerations section lacking per se, but do have these questions:
> >>
> >>   - Why require HTTPS for the reference case but not the value case
> >> (I can understand why you don't require it for the value case, but
> >> couldn't it be a choice for the PSAP also in the reference case?
> >> This would also seem to simplify during an introductory phase when
> >> a wide-spread PKI solution is not yet in place.)?
> >>
> >>
> >>  I'm very surprised that a security area person is asking why we
> >> don't make TLS optional!  It's a valid question, of course, just
> >> surprising in this context.  Because of the limited scope of the
> >> document, specifically emergency services, and given that the
> >> dereferencing entities will be PSAPs and other responders that have
> >> upgraded to support next-generation, we felt that it was reasonable
> >> to require the use of TLS and client-side certificates for dereferencing.
> >>
> >> - i.e., that the mutual auth option of TLS is being used, perhaps
> >> this needs to be clarified?
> >>
> >>
> >> spoofing issue - the PSAPs don't want to be overly susceptible to
> >> spoofed calls (although they rather err on the side of safety, of
> >> course. Thus, should integrity of infomation in the direct case be
> >> considered? I.e., by n/w or service providers in the path to the
> >> PSAP vouching for the information?
> >>
> >>
> >>  You're absolutely correct that PSAPs are concerned about spoofed
> >> (and other false) calls but will generally err by taking a call and
> >> asking the caller for information.  In general, PSAPs prefer
> >> information that comes from known and trusted providers (the major
> >> carriers). Are you suggesting a mechanism by which providers verify the information provided by the device?
> >> sanity-checking device-provided information (location or Wi-Fi APs)
> >> against network-known information (macro cell to which the device is associated).
> >>
> >>  --
> >>  Randall Gellens
> >>  -------------- Randomly selected tag: ---------------  In a sense,
> >> when we started Virgin Atlantic, I was trying to create  an airline
> >> for myself. If you try to build the perfect airline for  yourself,
> >> it will be appreciated by others. --Richard Branson, 1996.
> >>
> >>
> >>
> >>
> >>  --
> >>
> >>  -- Magnus
> >>
> >
> >
> >
> > --
> > Randall Gellens
> > -------------- Randomly selected tag: --------------- All we're
> > seeing is the negative side of nuclear war.
> >    --Barry Goldwater
> >
>
>
>
> --
> -- Magnus
>
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Sep 2015 09:14:05 -0700

At 7:38 AM +0000 9/16/15, [email-masked] wrote:

>  BCP195 has recent recommendations for most TLS 
> options. I'd say it'd be best to use those or 
> if not figure out why they're not correct for 
> this context.

Just to be clear: are you suggesting that we replace text suggested by Magnus:

    TLS MUST be version 1.2 or later.  It is RECOMMENDED to use only
    cypher suites that offer Perfect Forward Secrecy (PFS) and avoid
    Cipher Block Chaining (CBC), for example,
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

    TLS MUST be version 1.2 or later.  It is RECOMMENDED follow
    [BCP195].

Note that BCP 195 does not address CBC (but does 
discuss PFS).  I just want to be clear before 
making the change, so please confirm that this 
works.

-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 16 Sep 2015 10:31:39 -0700

Just a personal remark: BCP 195 still allows earlier versions of TLS, even
TLS 1.0. I felt that for a new application like this, one could go
stronger. Maybe  a combo - where you rely on BCP 195 but mandate TLS 1.2
(or later)?

On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <[email-masked]>
wrote:

>>  BCP195 has recent recommendations for most TLS options. I'd say it'd be
>> best to use those or if not figure out why they're not correct for this
>> context.
>>
>
> Note that BCP 195 does not address CBC (but does discuss PFS).  I just
> want to be clear before making the change, so please confirm that this
> works.
>
> --
> Randall Gellens

-- 
-- Magnus

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Sep 2015 10:57:59 -0700

At 10:31 AM -0700 9/16/15, Magnus Nyström wrote:

Just a personal remark: BCP 195 still
allows earlier versions of TLS, even TLS 1.0. I felt that for a new
application like this, one could go stronger. Maybe  a combo -
where you rely on BCP 195 but mandate TLS 1.2 (or later)?

And not mention CBC?

On Wed, Sep 16, 2015 at 9:14 AM, Randall
Gellens <[email-masked]>
wrote:

At 7:38 AM +0000 9/16/15, [email-masked]
wrote:

On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus
Nyström wrote:

Yes, at least mandating TLS 1.2 or higher and
recommending as per above

seems reasonable.

The references for the GCM suites would be RFC 5288 and RFC
5289.

BCP195 has recent recommendations for most TLS options. I'd say
it'd be best to use those or if not figure out why they're not correct
for this context.

Just to be clear: are you suggesting that we replace text suggested by
Magnus:

TLS MUST be version 1.2 or later.  It is RECOMMENDED
to use only

cypher suites that offer Perfect Forward Secrecy (PFS)
and avoid

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288]
[RFC5289].

With this:

TLS MUST be version 1.2 or later.  It is RECOMMENDED
follow

[BCP195].

Note that BCP 195 does not address CBC (but does discuss PFS).  I
just want to be clear before making the change, so please confirm that
this works.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

If the odds are a million to one against something occurring,
chances

are 50-50 it will.

--

-- Magnus

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

Between two evils, I always pick the one I never tried before.

--Mae West.

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 16 Sep 2015 11:19:11 -0700

Sorry, yes, also mention no CBC

-- 
-- Magnus

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Sep 2015 11:25:37 -0700

How do we want to word this?

The original wording based on your suggestions was:

The next revision was:

So how to we want to work CBC in to this?  And if 
we do, does that mean we need to also mention the 
specific cypher suites?

At 11:19 AM -0700 9/16/15, Magnus Nyström wrote:

>  On Wed, Sep 16, 2015 at 10:57 AM, Randall 
> Gellens 
>>  Just a personal remark: BCP 195 still allows 
>> earlier versions of TLS, even TLS 1.0. I felt 
>> that for a new application like this, one 
>> could go stronger. Maybe  a combo - where you 
>> rely on BCP 195 but mandate TLS 1.2 (or later)?
>>
>
>
>  And not mention CBC?
>
>
>>
>  At 7:38 AM +0000 9/16/15, 
> <mailto:[email-masked]>[email-masked] 
> wrote:
>
>  Note that BCP 195 does not address CBC (but 
> does discuss PFS).  I just want to be clear 
> before making the change, so please confirm 
> that this works.
>
>  --
>  Randall Gellens

-------------- Randomly selected tag: ---------------
Total deregulation would allow anybody to fly any route, a
situation that is unlikely ever to occur.
        --New York Times Magazine, 9 May 1976.

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 16 Sep 2015 11:50:20 -0700

That looks good to me.

On Wed, Sep 16, 2015 at 11:32 AM, Brian Rosen <[email-masked]> wrote:

>   cipher suites that offer Perfect Forward Secrecy (PFS), avoid
>   Cipher Block Chaining (CBC) and follow the recommendations in BCP195.
>
> > On Sep 16, 2015, at 12:14 PM, Randall Gellens <[email-masked]>
> wrote:
> >

-- 
-- Magnus

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Sep 2015 14:32:42 -0400

> On Sep 16, 2015, at 12:14 PM, Randall Gellens <[email-masked]> wrote:
> 
> Note that BCP 195 does not address CBC (but does discuss PFS).  I just want to be clear before making the change, so please confirm that this works.
> 
> --
> Randall Gellens

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Sep 2015 12:22:42 -0700

>    Cipher Block Chaining (CBC) and follow the recommendations in BCP195.

Do we need to give examples of such suites?

>>>  BCP195 has recent recommendations for most 
>>> TLS options. I'd say it'd be best to use 
>>> those or if not figure out why they're not 
>>> correct for this context.
>>

-------------- Randomly selected tag: ---------------
It takes a wonderful brain and exquisite senses to produce a few
stupid ideas.                                        --Santayana

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Sep 2015 15:38:55 -0400

Don’t think so.

Brian
> On Sep 16, 2015, at 3:22 PM, Randall Gellens <[email-masked]> wrote:
>