Re: [TLS] SSO Attacks in Browser

[Kathleen Moriarty]

Sent from my mobile device

> On Apr 11, 2022, at 6:31 PM, Eric Rescorla  wrote:
> 
> 
> Note that a password manager is a partial mitigation here, at least if it's 
> tied into the browser and automatically fills in based on origin, much like 
> WebAuthn is.
> 
> -Ekr
> 
> 
>> On Mon, Apr 11, 2022 at 3:13 PM Richard Barnes  wrote:
>> Just to be clear:
>> 
>> * These "picture in picture" attacks have been around for years, as Ben 
>> points out.
>> * WebAuthn is not vulnerable, because its assertions are bound to the 
>> origin, and a phishing site can't access the correct origin.
>> * Anything that doesn't involve asymmetric cryptography will be replayable, 
>> and thus perishable, through this attack or others.
>> 
Thank you. From a different thread, I thought WebAuthn was vulnerable. 

Best regards,
Kathleen 
>> 
>>> On Mon, Apr 11, 2022 at 5:21 PM Kathleen Moriarty 
>>>  wrote:
>>> Thank you, Ben.  Much appreciated. I’ll think about this a bit more and a 
>>> few others now are as well. 
>>> 
>>> Best regards,
>>> Kathleen 
>>> 
>>> Sent from my mobile device
>>> 
>>>>> On Apr 11, 2022, at 5:05 PM, Ben Schwartz  wrote:
>>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> Sent from my mobile device
>>>>> 
>>>>>>> On Apr 11, 2022, at 3:52 PM, Ben Schwartz  wrote:
>>>>>>> 
>>>>>> 
>>>>>> I think there may be a misunderstanding here.  According to my 
>>>>>> understanding, these attack pages do not need to contain any actual 
>>>>>> subresources from the SSO provider.  They simply provide a login UI that 
>>>>>> matches the appearance of the SSO login, in order to trick the user into 
>>>>>> entering their SSO credentials into an attacker-controlled tab.
>>>>>> 
>>>>>> This doesn't seem like something that can be fixed by the TLS working 
>>>>>> group.
>>>>> 
>>>>> Right, but maybe by people here who also work on the interfaces to where 
>>>>> credentials are stored?
>>>> 
>>>> This attack is on password-based security, so the credentials are stored 
>>>> in the user's head, and the user types them into an interface that they 
>>>> think is the SSO provider, but is in fact the attacker.  It's literally 
>>>> window-dressing on a standard old-fashioned phishing attack.  This page 
>>>> explains the technique: 
>>>> https://mrd0x.com/browser-in-the-browser-phishing-attack/
>>>>  
>>>>> It’s posed as a browser attack as that’s the current mechanism, but is 
>>>>> going after credentials to access SSO. I guess that could be replayed 
>>>>> later as well if only captured by this and doesn’t access the store, but 
>>>>> the article seems to say that the store is accessed.
>>>> 
>>>> That article appears to be an attempt to restate the original report on 
>>>> Ghostwriter published here: 
>>>> https://blog.google/threat-analysis-group/tracking-cyber-activity-eastern-europe/.
>>>>   It may be easier to understand the details from the original report.
>>>>  
>>>>> 
>>>>> Thanks for thinking about it,
>>>>> Kathleen 
>>>>> 
>>>>>> 
>>>>>>> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty 
>>>>>>>  wrote:
>>>>>>> This has to be dealt with at the container interface for non-browser 
>>>>>>> interfaces too, right?
>>>>>>> 
>>>>>>> If there are OASIS and W3C WebAuthn active participants, it would be 
>>>>>>> helpful to figure out the best place to deal with this issue.
>>>>>>> 
>>>>>>> Thank you and sorry for a second message.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Kathleen
>>>>>>> 
>>>>>>>> On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty 
>>>>>>>>  wrote:
>>>>>>>> Greetings!
>>>>>>>> 
>>>>>>>> In thinking about the attacks prompting for credentials to access SSO 
>

Re: [TLS] SSO Attacks in Browser

[Kathleen Moriarty]

Thank you, Ben.  Much appreciated. I’ll think about this a bit more and a few 
others now are as well. 

Best regards,
Kathleen 

Sent from my mobile device

> On Apr 11, 2022, at 5:05 PM, Ben Schwartz  wrote:
> 
> 
> 
> 
>> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty 
>>  wrote:
>> 
>> 
>> Sent from my mobile device
>> 
>>>> On Apr 11, 2022, at 3:52 PM, Ben Schwartz  wrote:
>>>> 
>>> 
>>> I think there may be a misunderstanding here.  According to my 
>>> understanding, these attack pages do not need to contain any actual 
>>> subresources from the SSO provider.  They simply provide a login UI that 
>>> matches the appearance of the SSO login, in order to trick the user into 
>>> entering their SSO credentials into an attacker-controlled tab.
>>> 
>>> This doesn't seem like something that can be fixed by the TLS working group.
>> 
>> Right, but maybe by people here who also work on the interfaces to where 
>> credentials are stored?
> 
> This attack is on password-based security, so the credentials are stored in 
> the user's head, and the user types them into an interface that they think is 
> the SSO provider, but is in fact the attacker.  It's literally 
> window-dressing on a standard old-fashioned phishing attack.  This page 
> explains the technique: 
> https://mrd0x.com/browser-in-the-browser-phishing-attack/
>  
>> It’s posed as a browser attack as that’s the current mechanism, but is going 
>> after credentials to access SSO. I guess that could be replayed later as 
>> well if only captured by this and doesn’t access the store, but the article 
>> seems to say that the store is accessed.
> 
> That article appears to be an attempt to restate the original report on 
> Ghostwriter published here: 
> https://blog.google/threat-analysis-group/tracking-cyber-activity-eastern-europe/.
>   It may be easier to understand the details from the original report.
>  
>> 
>> Thanks for thinking about it,
>> Kathleen 
>> 
>>> 
>>>> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty 
>>>>  wrote:
>>>> This has to be dealt with at the container interface for non-browser 
>>>> interfaces too, right?
>>>> 
>>>> If there are OASIS and W3C WebAuthn active participants, it would be 
>>>> helpful to figure out the best place to deal with this issue.
>>>> 
>>>> Thank you and sorry for a second message.
>>>> 
>>>> Best regards,
>>>> Kathleen
>>>> 
>>>>> On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty 
>>>>>  wrote:
>>>>> Greetings!
>>>>> 
>>>>> In thinking about the attacks prompting for credentials to access SSO 
>>>>> credentials in browsers, I am wondering if the fix is in the interface to 
>>>>> each type of storage container for credentials, e.g. OASIS PKCS#11, W3C 
>>>>> WebAuthn, and maybe OAuth if that has been hit as well by these attacks, 
>>>>> called "Browser in the Browser". 
>>>>> https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/
>>>>>  
>>>>> 
>>>>> Is there a way in the browser for an organization to configure (or can 
>>>>> there be in those interfaces) the only permitted addresses to prompt and 
>>>>> allow access to the interface, so not just the password is needed?  It 
>>>>> seems like the best place to fix it even though each organization would 
>>>>> have to enter an allow list. The alternative would be deny lists of all 
>>>>> the malicious sites performing this activity and that won't catch 
>>>>> everything.
>>>>> 
>>>>> Is this being discussed already somewhere? Hopefully. Perhaps there are 
>>>>> other ideas?
>>>>> 
>>>>> Thank you.
>>>>> -- 
>>>>> 
>>>>> Best regards,
>>>>> Kathleen
>>>> 
>>>> 
>>>> -- 
>>>> 
>>>> 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] SSO Attacks in Browser

[Kathleen Moriarty]

Sent from my mobile device

> On Apr 11, 2022, at 3:52 PM, Ben Schwartz  wrote:
> 
> 
> I think there may be a misunderstanding here.  According to my understanding, 
> these attack pages do not need to contain any actual subresources from the 
> SSO provider.  They simply provide a login UI that matches the appearance of 
> the SSO login, in order to trick the user into entering their SSO credentials 
> into an attacker-controlled tab.
> 
> This doesn't seem like something that can be fixed by the TLS working group.

Right, but maybe by people here who also work on the interfaces to where 
credentials are stored? It’s posed as a browser attack as that’s the current 
mechanism, but is going after credentials to access SSO. I guess that could be 
replayed later as well if only captured by this and doesn’t access the store, 
but the article seems to say that the store is accessed.

Thanks for thinking about it,
Kathleen 

> 
>> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty 
>>  wrote:
>> This has to be dealt with at the container interface for non-browser 
>> interfaces too, right?
>> 
>> If there are OASIS and W3C WebAuthn active participants, it would be helpful 
>> to figure out the best place to deal with this issue.
>> 
>> Thank you and sorry for a second message.
>> 
>> Best regards,
>> Kathleen
>> 
>>> On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty 
>>>  wrote:
>>> Greetings!
>>> 
>>> In thinking about the attacks prompting for credentials to access SSO 
>>> credentials in browsers, I am wondering if the fix is in the interface to 
>>> each type of storage container for credentials, e.g. OASIS PKCS#11, W3C 
>>> WebAuthn, and maybe OAuth if that has been hit as well by these attacks, 
>>> called "Browser in the Browser". 
>>> https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/ 
>>> 
>>> Is there a way in the browser for an organization to configure (or can 
>>> there be in those interfaces) the only permitted addresses to prompt and 
>>> allow access to the interface, so not just the password is needed?  It 
>>> seems like the best place to fix it even though each organization would 
>>> have to enter an allow list. The alternative would be deny lists of all the 
>>> malicious sites performing this activity and that won't catch everything.
>>> 
>>> Is this being discussed already somewhere? Hopefully. Perhaps there are 
>>> other ideas?
>>> 
>>> Thank you.
>>> -- 
>>> 
>>> Best regards,
>>> Kathleen
>> 
>> 
>> -- 
>> 
>> 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] SSO Attacks in Browser

[Kathleen Moriarty]

This has to be dealt with at the container interface for non-browser
interfaces too, right?

If there are OASIS and W3C WebAuthn active participants, it would be
helpful to figure out the best place to deal with this issue.

Thank you and sorry for a second message.

Best regards,
Kathleen

On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Greetings!
>
> In thinking about the attacks prompting for credentials to access SSO
> credentials in browsers, I am wondering if the fix is in the interface to
> each type of storage container for credentials, e.g. OASIS PKCS#11, W3C
> WebAuthn, and maybe OAuth if that has been hit as well by these attacks,
> called "Browser in the Browser".
> https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/
>
>
> Is there a way in the browser for an organization to configure (or can
> there be in those interfaces) the only permitted addresses to prompt and
> allow access to the interface, so not just the password is needed?  It
> seems like the best place to fix it even though each organization would
> have to enter an allow list. The alternative would be deny lists of all the
> malicious sites performing this activity and that won't catch everything.
>
> Is this being discussed already somewhere? Hopefully. Perhaps there are
> other ideas?
>
> Thank you.
> --
>
> Best regards,
> Kathleen
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] SSO Attacks in Browser

[Kathleen Moriarty]

Greetings!

In thinking about the attacks prompting for credentials to access SSO
credentials in browsers, I am wondering if the fix is in the interface to
each type of storage container for credentials, e.g. OASIS PKCS#11, W3C
WebAuthn, and maybe OAuth if that has been hit as well by these attacks,
called "Browser in the Browser".
https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/

Is there a way in the browser for an organization to configure (or can
there be in those interfaces) the only permitted addresses to prompt and
allow access to the interface, so not just the password is needed?  It
seems like the best place to fix it even though each organization would
have to enter an allow list. The alternative would be deny lists of all the
malicious sites performing this activity and that won't catch everything.

Is this being discussed already somewhere? Hopefully. Perhaps there are
other ideas?

Thank you.
-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-oldversions-deprecate-09

[Kathleen Moriarty]

Thank you, Mohit, Stephen, and Alyssa!

On Wed, Jan 20, 2021 at 2:34 PM Alissa Cooper  wrote:

> Mohit, thanks for your review. Stephen, thanks for your response. I
> entered a Yes ballot.
>
> Alissa
>
> On Nov 25, 2020, at 6:47 AM, Stephen Farrell 
> wrote:
>
>
>
> On 25/11/2020 11:46, Mohit Sethi via Datatracker wrote:
>
> Reviewer: Mohit Sethi
> Review result: Ready
>
>
> Thanks. Will look at those nits when next editing.
>
> Cheers,
> S.
>
> 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-oldversions-deprecate-09
> Reviewer: Mohit Sethi
> Review Date: 2020-11-25
> IETF LC End Date: 2020-11-30
> IESG Telechat date: Not scheduled for a telechat
> Summary: This document deprecates older versions of TLS and DTLS. It also
> updates many RFCs that normatively refer to the older TLS/DTLS versions.
> Major issues: None
> Minor issues: None
> Nits/editorial comments: In section 1.1, typo in "waas defined to detect".
> Most references to RFCs are of the form "[RFC7507]". Can we change "RFC
> 7457
> [RFC7457]" to "[RFC7457]" for uniformity. Similarly, perhaps you could
> change
> "RFC5246 [RFC5246]" and "RFC4346 [RFC4346]" to "[RFC5246]" and "[RFC4346]".
> In section 2 "NIST for example have provided " should be "..has
> provided...".
> In section 6 "this document is called out specifically to update text
> implementing the deprecation  recommendations of this document." I was
> initially confused with the repeated usage of "this". Perhaps it would
> help to
> be more explicit.
>
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>
>
>

-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Robert Wilton's No Objection on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

[Kathleen Moriarty]

Thank you for your careful review, the change looks good to me.

Best regards,
Kathleen

On Tue, Jan 19, 2021 at 10:07 AM Rob Wilton (rwilton) 
wrote:

> LGTM.
>
> Regards,
> Rob
>
>
> > -Original Message-
> > From: Stephen Farrell 
> > Sent: 19 January 2021 14:28
> > To: Rob Wilton (rwilton) ; The IESG 
> > Cc: draft-ietf-tls-oldversions-deprec...@ietf.org; tls-cha...@ietf.org;
> > tls@ietf.org
> > Subject: Re: [TLS] Robert Wilton's No Objection on draft-ietf-tls-
> > oldversions-deprecate-11: (with COMMENT)
> >
> >
> > Hiya,
> >
> > On 19/01/2021 11:05, Rob Wilton (rwilton) wrote:
> > >
> > >
> > >> -Original Message- From: iesg  On
> > >> Behalf Of Stephen Farrell Sent: 12 January 2021 21:35 To: Rob
> > >> Wilton (rwilton) ; The IESG  Cc:
> > >> draft-ietf-tls-oldversions-deprec...@ietf.org;
> > >> tls-cha...@ietf.org; tls@ietf.org Subject: Re: [TLS] Robert
> > >> Wilton's No Objection on draft-ietf-tls- oldversions-deprecate-11:
> > >> (with COMMENT)
> > >>
> > >>
> > >> Hiya,
> > >>
> > >> On 12/01/2021 18:14, Robert Wilton via Datatracker wrote:
> > >>> Robert Wilton has entered the following ballot position for
> > >>> draft-ietf-tls-oldversions-deprecate-11: 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-oldversions-deprecate/
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > --
> > >>> COMMENT:
> > >>>
> --
> > >>>
> > >>>
> > >>>
> > Thank you for purging the old versions of TLS.
> > >>
> > >> Thanks for trudging through it! :-)
> > >>
> > >>>
> > >>> There is one sentence in the abstract that I found surprising (if
> > >>> it is
> > >> right).
> > >>>
> > >>> The abstract states: "TLSv1.2 has been the recommended version
> > >>> for IETF protocols since 2008, providing sufficient time to
> > >>> transition away from older versions."
> > >>>
> > >>> Should this be "minimum recommended version"?  Otherwise, I
> > >>> don't
> > >> understand
> > >>> why the recommended version of TLS is 1.2 rather than 1.3 (given
> > >>> that
> > >> the TLS
> > >>> 1.2 RFC is marked as obsolete).
> > >>
> > >> I see what you mean.
> > >>
> > >> I guess s/has been/became/ would do it? The point isn't so much
> > >> what the current recommended version is/was but more that it's been
> > >> a dozen years since it was TLSv1.1.
> > > [RW]
> > >
> > > Yes, s/has been/became/ helps, but I still think that it implies that
> > > TLV 1.2 is the current recommended version of TLS.
> > >
> > > Perhaps something along the lines of:
> > >
> > > TLSv1.2 became the recommended version for IETF protocols in 2008
> > > (now obsoleted by TLSv1.3 in 2018), providing sufficient time to
> > > transition away from older versions."
> >
> > Sure. I did more or less that in the repo - [1] with
> > diff vs. -11 at [2]
> >
> > Cheers,
> > S.
> >
> > [1]
> >
> https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-
> > oldversions-deprecate.txt
> > [2]
> >
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tls-oldversions-deprecate-
> > 11.txt=https://raw.githubusercontent.com/tlswg/oldversions-
> > deprecate/master/draft-ietf-tls-oldversions-deprecate.txt
> >
> > >
> > > Regards, Rob
> > >
> > >
> > >>
> > >>
> > >> Cheers, S.
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>> ___ TLS mailing list
> > >>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> > >>>
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Éric Vyncke's Yes on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

[Kathleen Moriarty]

Thank you for your review and to Stephen for making the speedy updates.

Best regards,
Kathleen

On Tue, Jan 19, 2021 at 9:28 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 19/01/2021 10:23, Éric Vyncke via Datatracker wrote:
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-tls-oldversions-deprecate-11: Yes
> >
> > 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-oldversions-deprecate/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thank you for the work put into this document.
> >
> > Special thanks to the shepherd, Sean Turner, who did a great job to
> describe
> > the WG consensus. Rob Wilton's point about minimum version is also
> important
> > and should be addressed in the abstract (even if the text is clearer in
> section
> > 1).
> >
> > Please find below some nits.
> >
> > I hope that this helps to improve the document,
> >
> > Regards,
> >
> > -éric
> >
> > -- Abstract --
> > "This document, if approved, formally deprecates Transport Layer" =>
> should ",
> > if approved," be removed now from the abstract? The RFC Editor will
> probably do
> > it though.
>
> Yep, that's standard fare so fine to leave as-is since the
> RFC folks know what to do there already.
>
> >
> > -- Section 1 --
> > "deprecate these old versions." should the "these old version" be
> followed by
> > the enumeration ?
>
> Fair enough. I guess that snippet in isolation could be
> ambiguous. Also fixed in repo - [1] with diff vs. -11
> at [2]
>
> Cheers,
> S.
>
> [1]
>
> https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt
> [2]
>
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tls-oldversions-deprecate-11.txt=https://raw.githubusercontent.com/tlswg/oldversions-deprecate/master/draft-ietf-tls-oldversions-deprecate.txt
>
> >
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Kathleen Moriarty]

I disagree here as those other implementations just need to make their own 
business risk decisions and put in place an exception process.  One option in 
the risk decision process is to accept risk, you can also mitigate, eliminate, 
or transfer the risk.

Best regards,
Kathleen 

Sent from my mobile device

> On Dec 1, 2020, at 7:57 AM, Keith Moore  wrote:
> 
> On 12/1/20 4:29 AM, Peter Gutmann wrote:
> 
>> I think all it needs is something along the lines of "This BCP applies to TLS
>> as used on the public Internet [Not part of the text but meaning the area 
>> that
>> the IETF creates standards for].
> 
> Not specifically relevant to this draft, but:  Is it actually defined 
> anywhere that IETF standards only apply to the public Internet?  IMO IETF 
> needs to realize that implementations of its standards are used outside of 
> the public Internet and consider that when writing its documents.  (even 
> though different rules may be appropriate on private and mostly-isolated 
> networks)
> 
> Keith
> 
> p.s. I keep thinking that this "MUST NOT TLS < 1.2" recommendation is like a 
> public health recommendation, one that is worded over-simply to try to make 
> it have maximum useful effect but perhaps to the point of being misleading or 
> even harmful. e.g. "You MUST wear masks to reduce the spread of COVID-19", 
> but not saying "oh yeah, if you're outdoors and not around other people 
> you're probably fine without a mask" and "masks are pointless if you only 
> wear them over your mouths or chins", and "the masks that have valves in them 
> to allow exhaled breath to exit unimpeded are also useless for this purpose" 
> and "you need to wear them when indoors and around co-workers, not merely 
> when customers or visitors are present".  At least where I live I see so many 
> people using masks in ineffective ways that I don't think the simple 
> recommendation is working, though I'm not sure that a more detailed 
> recommendation would work better.
> 
> 

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

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Kathleen Moriarty]

Having risk management experience as well as policy establishment and 
enforcement, I would rather see the clear notification that something is not 
secure.  Then the organization makes the decision to take that risk based on 
likelihood/impact considerations.  This factors in risk tolerance and business 
objectives.  I am an author on the draft, and don’t think this is the place for 
those business decisions to be made.

Best regards,
Kathleen 

Sent from my mobile device

> On Dec 1, 2020, at 12:52 AM, Ben Smyth  wrote:
> 
> 
> I haven't followed all the nuances of this discussion, but it seems to boil 
> down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private 
> enterprise running legacy kit, which makes decision makers anxious, since 
> they don't want responsibility for something they "MUST NOT" do: A solution 
> might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing 
> sectors to define their standards/principles/expectations. 
> ___
> 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: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Kathleen Moriarty]

Hi Eliot,

Thanks for raising your concern.  I’ll note that I first started working on 
this because a well deployed library already had plans to drop support for 
versions 1.0 and 1.1 in their next release.  Customers that wanted those 
versions would have to use a prior library. This history may help.

Best regards,
Kathleen 

Sent from my mobile device

> On Nov 28, 2020, at 10:26 AM, Stephen Farrell  
> wrote:
> 
> 
> Hi Eliot,
> 
>> On 28/11/2020 10:45, Eliot Lear wrote:
>> Hi there IESG
>> I support the intent of this document, and I think the approach to
>> update the various documents listed is the right one.
> 
> Cool.
> 
>> Because of the breadth of documents updated, I wonder if at least
>> some implementation guidance is warranted, in order to assist
>> developers and even perhaps administrators.  Perhaps in some cases
>> these are compile-time or even run time options.  I’d suggest
>> guidance for common libraries, such as Microsoft .NET, OpenSSL,
>> GNUTLS, and WolfSSL. Better to give that guidance to get people to
>> TLS 1.3 rather than 1.2, of course.  Even informational references
>> would be fine, as assuredly some of this guidance exists.
> 
> Text welcomed of course, but I think it's mostly a case of
> doing the s/w update for the library and then either waiting
> 'till the library developer defaults to TLSv1.2 or better, or
> else various config file or API options that don't differ
> that much from library to library. I can check it out before
> we're done (again, text welcome if someone else wants to do
> that), but not sure it'll be that useful in the end TBH.
> (I'll get back when I get to doing that.)
> 
> Cheers,
> S.
> 
>> Thanks,
>> Eliot
 On 9 Nov 2020, at 23:26, The IESG  wrote:
>>> The IESG has received a request from the Transport Layer Security
>>> WG (tls) to consider the following document: - 'Deprecating TLSv1.0
>>> and TLSv1.1'  as Best
>>> Current Practice
>>> 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 last-c...@ietf.org mailing lists by 2020-11-30.
>>> 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, if approved, formally deprecates Transport Layer Security 
>>> (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those 
>>> documents (will be moved|have been moved) to Historic status.  These 
>>> versions lack support for current and recommended cryptographic algorithms 
>>> and mechanisms, and various government and industry profiles of 
>>> applications using TLS now mandate avoiding these old TLS versions.  
>>> TLSv1.2 has been the recommended version for IETF protocols since 2008, 
>>> providing sufficient time to transition away from older versions.  Removing 
>>> support for older versions from implementations reduces the attack surface, 
>>> reduces opportunity for misconfiguration, and streamlines library and 
>>> product maintenance.
>>> This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347), 
>>> but not DTLS version 1.2, and there is no DTLS version 1.1.
>>> This document updates many RFCs that normatively refer to TLSv1.0
>>> or TLSv1.1 as described herein.  This document also updates the
>>> best practices for TLS usage in RFC 7525 and hence is part of
>>> BCP195.
>>> The file can be obtained via 
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>>> 
>>> 
>>> 
>>> 
> No IPR declarations have been submitted directly on this I-D.
>>> The document contains these normative downward references. See RFC
>>> 3967 for additional information: rfc5024: ODETTE File Transfer
>>> Protocol 2.0 (Informational - Independent Submission Editor
>>> stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational -
>>> Independent Submission Editor stream) rfc5023: The Atom Publishing
>>> Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight
>>> Online Certificate Status Protocol (OCSP) Profile for High-Volume
>>> Environments (Proposed Standard - IETF stream) rfc5019: The
>>> Lightweight Online Certificate Status Protocol (OCSP) Profile for
>>> High-Volume Environments (Proposed Standard - IETF stream) rfc5018:
>>> Connection Establishment in the Binary Floor Control Protocol
>>> (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining
>>> with Chunks for the Internet Registry Information Service (Proposed
>>> Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the
>>> Internet Registry Information Service (Proposed Standard - IETF
>>> stream) rfc4976: Relay Extensions for the Message Sessions Relay
>>> Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The
>>> Message Session Relay Protocol (MSRP) (Proposed Standard - IETF
>>> stream) rfc4975: The Message Session Relay Protocol (MSRP)
>>> (Proposed Standard - IETF stream) 

Re: [TLS] Opsdir last call review of draft-ietf-tls-oldversions-deprecate-09

[Kathleen Moriarty]

Thank you for your review, Nagendra and finding several nits.  We'll
correct them.

Best regards,
Kathleen

On Mon, Nov 30, 2020 at 4:21 PM Nagendra Nainar via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Nagendra Nainar
> Review result: Ready
>
> Hi,
>
> I have reviewed this document as part of the Operational directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts per guidelines in RFC5706.
>
> Comments that are not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
>
> Version: draft-ietf-tls-oldversions-deprecate-09
>
> Overall Summary:
>
> This draft is deprecating TLS v1.0 and TLSv1.1 to reduce the opportunity
> for
> misconfiguration or security attack.
>
> The draft clarifies that these (to be obsoleted) versions of TLS must not
> be
> negotiated and further clarifies that the connection must be terminated
> upon
> receiving such version in the initial negotiation.
>
> Overall this is a well-written document with clear clarification on any
> backward compatibility requirement.
>
> I just noticed a couple of nits some of which were already mentioned in
> other
> reviews as well. I am including the same here for completeness:
>
> 1. s/waas defined/was defined
> 2. Some text appears to use DTLS while other use (D)TLS. I think it is
> better
> to use one common way of defining it.
>
> Thanks,
> Nagendra
>
>
>

-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Sabotage?

[Kathleen Moriarty]

Hi Mike,

This is a pretty big topic that’s been explored quite a bit.  The long term 
impact of these changes could be very positive.  I just published a book on the 
topic of embracing E2E among other topics after exploring the impact on 
operators in RFC8404.  In other words, both directions were explored to reach a 
possible way forward with increased security and how to get the 
control/visibility in order to embrace these changes.  

I’m happy to talk more, but fear the length of a thread on this list and may 
not keep up with it given my current workload.

Best regards,
Kathleen 

Sent from my mobile device

> On Sep 12, 2020, at 11:07 AM, Michael D'Errico  wrote:
> 
> Hi,
> 
> I get a weird feeling that the internet is being hijacked and soon it will be 
> impossible to reverse course.  I have not followed the development of TLS 1.3 
> but it seems very different from TLS 1.2. Also TLS 1.2 is very different from 
> TLS 1.0/1.1 (which are being deprecated).  QUIC looked good at a glance, but 
> it seems to rely on TLS to share key material, and also I'm more than a bit 
> concerned about its capability to track users.
> 
> Then there's Zoom video conferencing, where everybody working from home or in 
> virtual school has an audio and video feed streaming to their servers.  
> Github is owned by Microsoft with some dire consequences.  Lots of large 
> companies trying to be everything to everyone, and it turns out they're cruel.
> 
> Anyone?
> 
> Mike
> 
> ___
> 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] AD review of draft-ietf-tls-oldversions-deprecate-06

[Kathleen Moriarty]

Hi Ben,

Thanks for your review.  Some initial responses are inline.

On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:

> Thanks for putting together the -06 based on my preliminary comments, and
> my apologies for taking so long to get back to it.  It turns out that going
> through the 80-odd documents we update takes a while!
>
>
> I have a bunch of suggestions that are basically editorial, that I'll
> make a pull request for (along with suggested changes for several of the
> following comments).  It's up at:
> https://github.com/tlswg/oldversions-deprecate/pull/3


Thanks for that!

>
>
> We mention in the Abstract (but not Introduction!) that this document
> moves 2246 and 4346 (but not 6347!) to the historic state.
> Unfortunately, this is slightly problematic from a process perspective,
> since the current way to make things Historic
> (
> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20
> )
> requires a separate "status change document" that gets its own IETF LC,
> to effectuate the status change.  Most references to the status change
> document can be replaced by this RFC after it's published, but formally
> the move to historic is *not* done by this document.  I've pulled into
> my pull request the language used in RFC 8429 to describe moves to
> Historic; please make sure to reproduce that language in the
> Introduction as well as the Abstract.
>

Do you need us to submit a draft to request that status change?

>
> I found three documents (3656, 4540, 7562) in the list of update targets
> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> preliminary review, and in principle it is permissible to make those
> updates as part of this document, but we will need specific ISE approval
> to do so.  I am supposed to sync up with him during IETF LC, but the
> document needs to be updated to clarify that the updates of ISE
> documents are/will be done with permission of the ISE.  (Please also try
> to double-check that the list is complete; I didn't find an
> authoritative list of "all documents on the ISE stream" to grep against,
> and I didn't try to have something parse rfc-index.xml to output such a
> list.
>

OK, so you'd like a list added and that's not in your pull request, is that
right?  We'll figure it out. Thanks in advance with the coordination with
Adrian.


>
> I note that in addition to our BCP 195 update (called out in Section 6),
> we also update 3552, which is BCP 72.  This update is quite incidental
> (compared to our BCP 195 update), so it seems clear that having this
> document be part of BCP 195 is correct.
>

Are you asking here to include an update to RFC3552?   Thanks.

>
> Section 1.1
>
> I went through all 83 of the references in the big list, that are
> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> as well as the shorter list of already-obsoleted documents.
>
> I won't bore you with my full notes, but there are some particular
> things that stood out from the review:
>
> - We have a separate list of updates for documents that are already
>   obsolete (but don't say much about why we're going go the extra
>   bother).  However, three of the documents in our main list of updates
>   (4743, 4744, and 6460) are already Historic, and presumably should be
>   treated more like the already-obsolete ones.
>

Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
extra step to say not to use it and it triggers many to begin phase out
plans.  Am I misunderstanding the question?


>
> - Several documents (e.g., 8261, 5023) specifically have MUST-level
>   requirements for 1.0 (or 1.1) that disappear or become internally
>   inconsistent with our current update, so we might want to fill that
>   void.
>

I'm not sure what you mean here.  This draft will update the ones listed.
RFC8261 just has the following:
"The DTLS implementation MUST support DTLS 1.0 [RFC4347
] and SHOULD

   support the most recently published version of DTLS, which was DTLS

   1.2 [RFC6347 ] when this RFC was
published. "

This deprecates DTLS1.0.  Are you asking for us to add a MUST support
DTLS1.2?

For RFC5023, there's the following text:
"At a minimum, client and server

   implementations MUST be capable of being configured to use HTTP Basic
   Authentication [RFC2617 ] in
conjunction with a connection made with
   TLS 1.0 [RFC2246 ] or a
subsequent standards-track version of TLS
   (such as [RFC4346 ]),
supporting the conventions for using HTTP over

   TLS described in [RFC2818 ]."

This requires a lot of updates, but in terms of the text for TLS as it
pertains to this draft, there's already text that says 

Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

[Kathleen Moriarty]

Thank you, Joe.

Sent from my mobile device

> On Jun 25, 2020, at 1:10 AM, Joseph Salowey  wrote:
> 
> 
> Hi All,
> 
> I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the 
> recommended IANA registry entries for  rsa_pkcs1_sha1 and ecdsa_sha1 in the 
> Signature Scheme registry from Y to N.   This change can be incorporated with 
> any updates from the AD review.  
> 
> Please post to this thread if you have any concerns with this change.  
> 
> Cheers,
> 
> Joe
> 
> [1] https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7
> 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

[Kathleen Moriarty]

On Mon, Jan 6, 2020 at 10:17 AM Stephen Farrell 
wrote:

>
> Hi all,
>
> I've just submitted -06 that (I think/hope:-) addresses
> the issues in Ben's preliminary AD review.
>

Thank you!

>
> So the ball's back in Ben's court until he finds more
> stuff that needs fixing or starts IETF LC:-)
>
> Cheers,
> S.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Wed, Dec 18, 2019 at 1:20 PM Russ Housley  wrote:

> I support the progress of this document, but I have one tardy comment.
>
> I think that Section 6 should have some introductory text similar to the
> text at the beginning of Section 7.
>

Thank you, Russ.

>
> Russ
>
>
> > On Dec 17, 2019, at 3:21 PM, Sean Turner  wrote:
> >
> > The WGLC ended on Friday.  A couple of comments were received and need
> to be addressed prior to progressing the draft to Ben.  We will put the
> document in the “Revised I-D Needed” state.
> >
> > Thanks,
> >
> > spt
> >
> >> On Nov 21, 2019, at 17:41, Sean Turner  wrote:
> >>
> >> All,
> >>
> >> This is the working group last call for the "Deprecating MD5 and SHA-1
> signature hashes in TLS 1.2" draft available
> https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.
> Please review the document and send your comments to the list by 2359 UTC
> on 13 December 2019.
> >>
> >> Note the the GH repo for this draft can be found at:
> >> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
> >>
> >> Cheers,
> >>
> >> Joe, Chris, 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
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

[Kathleen Moriarty]

Hi Ben,

Just replying to the parts of the tread that were not responded to already
as Stephen will likely be looking at the headers/updates per his message.
Thanks for your careful review.

On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk  wrote:

> Hi all,
>
> This is a "preliminary" review only because there's some strangeness
> relating to the Updates: (and Obsoletes:) headers, and any changes there
> would make me need to go and recheck the relationship of this document to
> the ones listed.  So, I haven't done any of that yet, in an attempt to only
> have to do it once.
>
> Specifically, there's skew between the list of documents updated in the top
> header and the list in Section 1.1.  Evern more annoyingly, the (tools)
> HTML version seems to be missing some numbers from the document header,
> that are present in the TXT version.  (Henrik is going to take a look, per
>
> https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU
> .)
>

Thanks.

>
> Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but
> there is no "Obsoletes:" header at the top of the document.
>
> I think nits is right about references (square-bracketed "[RFC6347]") in
> the Abstract; we should change those to normal textual (parenthesed
> "(RFC 6347)") before IETF LC.
>
> Some other notes from a quick pass over the main text (though I'll probably
> read it again once the above are addressed) follow.
>
> Section 1
>
> It feels a little backwards for a "primary technical reason" to
> deprecate a protocol version being that "at least one widely-used
> library has plans to drop [it]".
>

I see what you are saying.  The major library dropping it has to do with
the number of versions available and supporting them all is cumbersome and
could lead to configuration errors on the part of the user.  Would you just
like "primary" removed or would you prefer more of a change to the text?


>
> I do appreciate that we give discussion about what we intend
> "deprecation" to mean and for whom -- thank you for that!
>
> Section 2
>
>   TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant
>   change to TLS that aims to address threats that have arisen over
>   the years.  Among the changes are a new handshake protocol, a new
>   key derivation process that uses the HMAC-based Extract-and-Expand
>   Key Derivation Function (HKDF), and the removal of cipher suites
>   that use static RSA or DH key exchanges, the CBC mode of
>   operation, or SHA-1.  The list of extensions that can be used with
>   TLS 1.3 has been reduced considerably.
>
> While it's true that the initial list of extensions usable with TLS 1.3
> is smaller than the list of extensions usable at TLS 1.2 taken at the
> same time, it's also true that the requirements for allocating a new
> extension codepoint have been reduced dramatically.  So I think I'd say
> that this reflects not a desire to reduce the attack surface (as
> "measured" by number of extensions) but rather a paradigm shift in how
> the protocol works, which leaves some existing functionality
> incompatible with the new model.  I don't really get a clear sense of
> what this current last sentence is trying to say (i.e., whether it's one
> of those two descriptions I offered above).
>

Would you prefer "a significant change", be "a paradigm shift"? If not,
could you propose text?



> Section 3
>
>Similarly, the authentication of the handshake depends on signatures
>made using SHA-1 hash or a not stronger concatenation of MD-5 and
>SHA-1 hashes, allowing the attacker to impersonate a server when it
>is able to break the severely weakened SHA-1 hash.
>
> My recollection of the WG discussions (which I will go review) is that
> we don't really have consensus on the "not stronger" portion of this.
> Is that a key component of the document here?  (N.B. this is *not* an
> invitation to rehash that discussion again!  The chairs or I can provide
> a summary of points not resolved by previous discussion and points
> believed to be adequately agreed upon, which would be a trigger for any
> additional discussion that might be needed.)
>

Since you are already looking at the consensus of this with the chairs, we
can wait for your guidance.

Best regards,
Kathleen

>
> Thanks for putting this document together (I know that getting all the long
> list of references/updates/etc. right is really tedious and frustrating),
> and sorry to have been sitting on it for so long.
>
> -Ben
>


-- 

Best regards,
Kathleen
___
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

[Kathleen Moriarty]

On Tue, Oct 1, 2019 at 4:00 AM John Mattsson  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.


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

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

[Kathleen Moriarty]

On Tue, Oct 1, 2019 at 3:58 AM John Mattsson 
wrote:

> Kathleen Moriarty  wrote:
>
> >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?
>
> NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I
> think that is a good and ambitious plan. In fact it would be very good if
> IETF agreed on the same requirement.
>

Right, so they are not saying TLSv1.2 can't be used at that time, only that
TLSv1.3 must be supported.

"It requires that TLS 1.2 configured with FIPS-based cipher suites be
supported by all government TLS servers and clients and requires support
for TLS 1.3 by January 1, 2024. "

This is a good goal and fairly reasonable given that a number of customers
are asking for TLSv1.3.  Government customers will drive this further in
the US.


>
> > I think encouraging implementation of TLSv1.3 is good and important, but
> are there other ways besides deprecation?
>
> Yes, I think there is at least two things IETF can do:
>
> - The first thing is to do like NIST and already now give implementors a
> date when support for TLS 1.3 is required.
>

We've never done that as far as I know?  SHould we?  Or should this be left
to documents like NIST's and other regulatory requirements that drive
customer purchasing decisions?


>
> - The second thing is to do like 3GPP and mandate support for TLS 1.3 in
> new implementations and deployments.
>

The second is typical from the point of publication.  So back when I was an
AD, we were already looking for TLS mentions in drafts and once TLSv1.3 was
published, is when you switch from the prior version being required to
support for TLSv1.3 being required.  I'm guessing this continued
(especially with Eric as an AD for another year after I stepped down), but
I am not watching closely.


> This would avoid two thing that happened in the past. First, IETF
> published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2
> almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7
> months after publishing a draft relying on DTLS 1.0, IETF started working
> on a draft forbidding it’s use.
>

Unfortunately, things like that do happen, but shouldn't.  In some
instances, an explanation is made as to why an older version is required
and it's an exception.  Was that the case?  (Sorry I don't have the time to
research the old discusses and history of the RFC at the moment).

It's not the right thing, but with TLS versions, they usually stick out a
bit when you read a draft and it's an easy thing to catch if you're
skimming a draft as an AD with 400 pages of reading to get through for a
telechat.

Bets regards,
Kathleen


> Cheers,
> John
>
> -Original Message-
> From: Kathleen Moriarty 
> Date: Thursday, 26 September 2019 at 15:50
> To: "Salz, Rich" 
> Cc: John Mattsson , "TLS@ietf.org" <
> TLS@ietf.org>, "s...@ietf.org" 
> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
>
>
>
> 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 t

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

[Kathleen Moriarty]

On Tue, Oct 1, 2019 at 4:04 AM John Mattsson  wrote:

> Hi,
>
> I think draft-ietf-tls-oldversions-deprecate needs to update
> draft-ietf-rtcweb-security-arch as well.
>
> draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support
> of DTLS 1.0.
>
>   "Earlier drafts of this specification required DTLS
>   1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
>   at the time of this writing some implementations do not support DTLS
>   1.2; endpoints which support only DTLS 1.2 might encounter
>   interoperability issues."
>
> Good catch.


> You should check if there are more drafts in the publication process that
> needs to be updated.
>

This is something the security directorate should be watching for to check
in reviews prior to publication.  The ADs will also be adding this to their
list of things to look for in drafts that are in the publication queue as
that's been the practice for some time.  A proactive search could be
helpful, but having the stop gap in place is likely best as it could come
in in drafts that have not been written yet.

Best regards,
Kathleen

>
> Cheers,
> John
>
> -Original Message-
> From: TLS  on behalf of Sean Turner via Datatracker
> 
> Date: Friday, 28 June 2019 at 15:14
> To: "ka...@mit.edu" 
> Cc: "iesg-secret...@ietf.org" , "
> tls-cha...@ietf.org" , "TLS@ietf.org" 
> Subject: [TLS] Publication has been requested for
> draft-ietf-tls-oldversions-deprecate-05
>
> Sean Turner has requested publication of
> draft-ietf-tls-oldversions-deprecate-05 as Best Current Practice on behalf
> of the TLS working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-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
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Tue, May 14, 2019 at 12:33 PM David Benjamin 
wrote:

> > which exact piece of popular software actually still does that?
>> > It ain't curl, it ain't Chrome, it ain't Firefox.
>>
>> It definitely was implemented in Chrome and Firefox, which is how this
>> poor document got onto standards track:
>>
>>https://tools.ietf.org/html/rfc7507
>>
>>  TLS Fallback Signaling Cipher Suite Value (SCSV)
>> for Preventing Protocol Downgrade Attacks
>>
>> >
>> > It also isn't something done automatically
>> > by any TLS implementation that's even remotely popular:
>> > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...
>>
>> It is impossible to do this transparently, because the a connection
>> is ususable after a fatal TLS hanshake failure (or unexpected socket
>> closure).
>>
>> Any application-level cleartext negotiation will have to be repeated
>> as well, and the TLS implementation typically does not know about it.
>> (such as HTTP CONNECT or STARTTLS)
>>
>> The POODLE paper
>>https://www.openssl.org/~bodo/ssl-poodle.pdf
>>
>> asserts that many clients doing downgrade dances exist, and at the
>> time of publication, this includes Mozilla Firefox, Google Chrome and
>> Microsoft Internet Explorer.
>>
>
> Chrome has not done a downgrade dance for over three years now (Chrome 50,
> released in April 2016), even for TLS 1.3. Indeed much of the fuss around
> TLS 1.3 was so clients could avoid repeating this mess.
>

Martin,

There's also value in people having fewer choices as security problems are
often the result of misconfigurations.  A lower number of protocols to
support, chose from, and configure correctly is helpful to the larger
number of implementers.  Additionally, there is at least one library that
planned to remove support for 1.0 and 1.1.  This means that is product
teams need to continue support, they have to run an older version of the
library, plus newer ones for 1.3.  This gets messy and increases the chance
of error.  The chance of misconfiguration is not insignificant (by product
teams or implementers of those products).

Best regards,
Kathleen


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


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Mon, May 6, 2019 at 1:45 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> On 5/6/19, 7:22 AM, "TLS on behalf of Hubert Kario"  on behalf of hka...@redhat.com> wrote:
> > Sure, and that was the really strange thing with TLS 1.2, why not
> just say
> > SHA-2 or better only, rather than adding mechanisms that were much,
> much
> > weaker than its predecessors?  So the simple fix is just to use
> SHA-2 only
> > for TLS 1.2.
>
> I don't know as I wasn't there when that was discussed, but one reason
> could
> be the same as the problems we are facing now with RSA-PSS in TLS 1.3:
> smartcards and HSMs that are limited to old algorithms.
>
> HSMs are more likely than not to support SHA-2. Smartcards rarely perform
> hash themselves, relying on the software that uses them.
>
>
> Also, don't forget that signature_algorithms, at least in theory[1],
> was
> supposed to also influence server certificate selection, and SHA-1 was
> used in
> vast majority of certificates in PKI.
>
> Alas. Only in some (albeit large) enclaves.
>

Is this better suited for another (short) draft?

Best,
Kathleen

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


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Mon, May 6, 2019 at 10:39 AM Benjamin Kaduk  wrote:

> On Sat, May 04, 2019 at 09:00:17AM -0400, Kathleen Moriarty wrote:
> > On Fri, May 3, 2019 at 10:46 PM Peter Gutmann  >
> > wrote:
> >
> > > Kathleen Moriarty  writes:
> > >
> > > >MD5 is not discussed in the current version of RFC7525.
> > >
> > > I would add it, if this is guidance for general use then it should
> cover
> > > all
> > > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY
> MUST
> > > NOT.
> > >
> > > (Technically SHA-1 is still safe for ephemeral signing, i.e. locations
> > > where
> > > an attacker can't spend arbitrary amounts of time working on
> precomputed
> > > data,
> > > which is most of TLS because of the nonces in the handshake and the
> fact
> > > that
> > > connections will quickly time out if nothing arrives, but since TLS
> 1.2 has
> > > SHA-2 built in already there's probably little point in separating out
> > > where
> > > SHA-1 is safe vs. where it isn't).
> > >
> >
> > Sure, I agree, but needed to look through prior documents first.  Since
> it
> > wasn't in RFC7525 as a recommendation and the minimum baseline was above
> > MD5, I suspect that is why it is not mentioned.   If there is support
> (and
> > no disagreements) the text above could be added and include SHA-1 and MD5
> > MUST NOT be used.  The minimum baseline is already set above it though in
> > the statement.
> >
> > WG decision is appreciated on this point and proposed text for RFC 7525.
> >
> > Proposed:
> >
> >When using RSA, servers SHOULD authenticate using certificates with
> >at least a 2048-bit modulus for the public key.  In addition, the use
> >of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and
> > MD5 MUST not be used (see [CAB-Baseline
> > <https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
> >more details).  Clients SHOULD indicate to servers that they request
> >SHA-256, by using the "Signature Algorithms" extension defined in
> >TLS 1.2.
>
> We'd probably want to wordsmith it a bit more, as there's not exactly a
> strict ordering on hash function strength, and "minimum requirement"
> could be taken to mean "MUST use SHA-256", which is presumably not the
> intent.
>

If this goes in, suggestions are welcome as we're trying to wrap this up.
If it's a separate document, then I think we're done with the last call
comments.

Thanks,
Kathleen

>
> -Ben
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Fri, May 3, 2019 at 10:46 PM Peter Gutmann 
wrote:

> Kathleen Moriarty  writes:
>
> >MD5 is not discussed in the current version of RFC7525.
>
> I would add it, if this is guidance for general use then it should cover
> all
> the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST
> NOT.
>
> (Technically SHA-1 is still safe for ephemeral signing, i.e. locations
> where
> an attacker can't spend arbitrary amounts of time working on precomputed
> data,
> which is most of TLS because of the nonces in the handshake and the fact
> that
> connections will quickly time out if nothing arrives, but since TLS 1.2 has
> SHA-2 built in already there's probably little point in separating out
> where
> SHA-1 is safe vs. where it isn't).
>

Sure, I agree, but needed to look through prior documents first.  Since it
wasn't in RFC7525 as a recommendation and the minimum baseline was above
MD5, I suspect that is why it is not mentioned.   If there is support (and
no disagreements) the text above could be added and include SHA-1 and MD5
MUST NOT be used.  The minimum baseline is already set above it though in
the statement.

WG decision is appreciated on this point and proposed text for RFC 7525.

Proposed:

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and
MD5 MUST not be used (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.


Best regards,
Kathleen

>
> Peter.
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Fri, May 3, 2019 at 4:09 PM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
>
> Sent from my mobile device
>
> On May 3, 2019, at 3:56 PM, Eric Rescorla  wrote:
>
>
>
> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann 
> wrote:
>
>> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what
>> the
>> original discussion was about, why not also add MUST NOT MD5 and SHA1 in
>> TLS
>> 1.2 to the text?
>>
>
> This seems like a reasonable proposal.
>
>
> If added, should this just be in the updates section for RFC7525?
>

If done here, the text below would change to MUST and we'd likely need
another WGLC, correct?

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.


The MUST NOT for SHA-1 is not clearly stated in RFC7525 as far as I can see.


Proposed:

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1
MUST not be used (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.


MD5 is not discussed in the current version of RFC7525.


Best regards,

Kathleen


> Best regards,
> Kathleen
>
>
> -Ekr
>
>
>> Peter.
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Sent from my mobile device

> On May 3, 2019, at 3:56 PM, Eric Rescorla  wrote:
> 
> 
> 
>> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann  
>> wrote:
>> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
>> original discussion was about, why not also add MUST NOT MD5 and SHA1 in TLS
>> 1.2 to the text?
> 
> This seems like a reasonable proposal.

If added, should this just be in the updates section for RFC7525?

Best regards,
Kathleen 
> 
> -Ekr
> 
>> 
>> Peter.
>> 
>> ___
>> 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 "Deprecating TLSv1.0 and TLSv1.1"

[Kathleen Moriarty]

On Thu, May 2, 2019 at 7:51 PM Martin Thomson  wrote:

> Thanks Kathleen, these look like good changes.
>
> Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/on/
>

Thank you, Martin!


>
> On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote:
> > Thank you for your feedback in this review. Responses inline as to how
> > I propose it is addressed:
> >
> > On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson 
> wrote:
> > > Section 1.1 doesn't say *how* those listed documents are updated.
> Might pay to include a few works on how.
> >
> > Thank you, that was helpful feedback. I changed the introduction text
> > as follows:
> > OLD:
> > This document updates these RFCs that normatively reference TLSv1.0 or
> > TLSv1.1 or DTLS1.0 and have not been obsoleted.
> > NEW:
> >  This document updates the following RFCs that normatively reference
> > TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of these
> > older versions. Fallback to these versions are prohibited through this
> > update.
> >
> > >  Section 2 can be cut down a lot. The quote from another document is
> longer than the rest of the text. In many ways, saying that the IETF is
> moving last is not a great thing to memorialize in RFC, as much as it is
> useful in an Internet-Draft or in argumentation in support of publication
> of the doc.
> >
> > A bunch has been cut out already, but I propose also cutting out the
> > following text to address your specific point (well taken):
> > 1st paragraph and last 2.
> >
> > REMOVE:
> >  Industry has actively followed guidance provided by NIST and the PCI
> >  Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2
> >  should remain a minimum baseline for TLS support at this time.
> >
> >  The Canadian government treasury board have also mandated that these
> >  old versions of TLS not be used.
> >
> >  Various companies and web sites have announced plans to deprecate
> >  these old versions of TLS.
> >
> >
> > >  The title of Section 3 could be a bit clearer.
> > Proposed:
> > SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1
> >
> > If you have a more terse suggestion, please post. I agree this should
> > be more clear.
> > >
> > >  It might pay to explain what RFC 7525 is in Section 6. Why does that
> document warrant special attention over the 70-odd other ones.
> >
> > Good point, how about the following text:
> >
> > PROPOSED:
> > RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer
> > Security (TLS) and Datagram Transport Layer Security (DTLS)", is the
> > mpost recent best practice document for implementing TLS and was based
> > off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not
> > yet been deprecated. As such, this document is called out specifically
> > to update text implementing the deprecation recommendations of this
> > document.
> >
> > >
> > >  Otherwise, publish this.
> >
> > Thank you!
> >
> > I'll continue through the rest of the messages, but may have a delay
> > when tending to other responsibilities.
> > I am putting the proposals into a new version to upload to the git
> > repository.
> >
> > Best regards,
> > Kathleen
> >
> > >
> > >
> > >
> > >  On Sat, Apr 13, 2019, at 09:28, 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.
> > >  >
> > >  > 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
> >
> >
> > --
> >
> > Best regards,
> > Kathleen
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Hello Martin,

On Tue, Apr 30, 2019 at 7:50 PM Martin Rex  wrote:

> Martin Thomson  wrote:
> > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
> >> The sound-bite version is: first raise the ceiling, *then* the floor.
> >
> > Yep.  We've done the ceiling bit twice now.
> > Once in 2008 when we published TLS 1.2 and then in 2018
> > with the publication of TLS 1.3.  I'd say we're overdue for the floor
> bit.
>
> Just that this rationale is a blatant lie.
>
> It is formally provable that from the three protocol versions:
>
>  TLSv1.0, TLSv1.1, TLSv1.2
>
> the weakest one is TLSv1.2, because of the royally stupid downgrade
> in the strength of digitally signed.
>
>
> Disabling TLSv1.0 will only result in lots of interop failures
> and pain, but no improvement in security.
>
>
I believe this is the last outstanding comment, pending a reference. Thank
you for your review and contribution.

Best regards,
Kathleen

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


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Fri, Apr 26, 2019 at 5:29 PM Viktor Dukhovni 
wrote:

> > On Apr 26, 2019, at 11:24 AM, Salz, Rich  wrote:
> >
> > If they haven’t already moved off TLS 1 then maybe this document will
> give the right people a push to do so.
> >
> > Nobody is going to arrest an MTA for non compliance.
>
> Of course.
>
> And as I said, I'd like to see the document move forward, I just
> wanted to see whether there was any appetite for adding some
> operator guidance.  It's not an issue of internet policing,
> rather it is a question of whether there should advice for
> operators who are considering disabling the legacy protocols.
>
> The sound-bite version is: first raise the ceiling, *then* the floor.
>
> The advice would therefore be for everyone to first make sure that
> their systems support at least TLS 1.2, and not just the now deprecated
> versions.  And then check whether the same holds true for their application
> ecosystem and if so disable the protocols at that time.
>
> In unauthenticated opportunistic TLS where cleartext is used when TLS
> handshakes fail, removing support for TLS 1.0 can reduce security in the
> short term (some messages needlessly going in cleartext).  Yes, this may
> be what it takes to finally get the long tail procrastinators to upgrade.
>
> The operational question then boils down to timing: when is your
> application
> ecosystem ready to drop the training wheels.
>
> Anyway, it does not look like there's much interest in adding operational
> considerations, which users will then perhaps learn about elsewhere if
> need be.  That's fine...
>

Thanks for your follow up assessment on this from the WG.  It seems we are
in agreement.

I appreciate your review, consideration, and attention to deployment
statistics for this move.

Best regards,
Kathleen

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


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Victor,

Thank you very much for your work and pushing the points on uses of TLS
outside of web as this is an important point.

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

My take on deprecation drafts is that once published, they take time
(years) before there is compliance.  Even with that, we may never achieve
full compliance and older version use continues. We do know that OpenSSL
will continue to support the version that came out last fall for 5 years
from that point in time.  Publication of the draft does not mean support
goes away at that point in time, but provides another push.  If there's a
strong feeling that text should be added, we could, but my preference would
be to leave it to the normal process for deprecation.

Thank you,
Kathleen


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


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Hi Gary,

Thanks for your review and support.  I'll respond inline and if Stephen
disagrees, he will chime in :-)

On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski  wrote:

> On 4/12/19 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.
>
> I think the document should be published.
>
> I agree with Martin Thomson's observation that the SP 800-52r2 quotes in
> Section 2 are a bit prolix considering the relatively small content that
> would remain if excised, and that NIST document has been in draft for a
> prolonged time (reducing its authority). The quotes imply but do not demand
> disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to
> mean that use of TLS 1.2 rather than TLS 1.3 is sinful.
>

I had interpreted Martin's comment's a little differently and cut out other
text.  Hmm, for the NIST quotes, I see this as providing the supporting
reasons and their recommendations not being the same as the recommendations
in this draft.  I think by the updated text Marten suggested on "updates",
this point is addressed, but please let us know if you feel otherwise.

> An additional (congenial) informative reference could be BSI TR-02102-2
> found at
>
>
> https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html
>
> which in §3.2 states "TLS 1.0 and TLS 1.1 are *not recommended*".
>

Thank you for the reference, it's probably bets to have a couple of sources
here.  I included the following text with the pdf reference included in the
working copy:

The German Federal Office for Information Security, recommends against use
of TLS versions less than 1.2 in the publication Cryptographic Mechanisms: Recommendations and Key Lengths

Best regards,
Kathleen


> Regards,
>
> Gary
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Maarten,

On Wed, Apr 24, 2019 at 3:43 AM Maarten Aertsen (NCSC-NL)  wrote:

> Hi,
>
> On 13-4-2019 01:28, 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.
>
> I'd like to see this published.
>
> @Kathleen, Stephen: in case there's any value in an additional ref for
> section 2, we published updated TLS-guidelines yesterday, with clear
> advice to phase out TLSv1, TLSv1.1.
>
>
> https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.html


Thank you for your review and this additional information, it's great to
see more traction on this.  Since we've greatly reduced section 2, cutting
out this type of data, we'll leave it out.  It's in the mail archive now
though.  If there are disagreements on this text having been cut, please
speak up!

Best regards,
Kathleen

>
>
> kind regards, Maarten
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Thank you for your feedback in this review.  Responses inline as to how I
propose it is addressed:

On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson  wrote:

> Section 1.1 doesn't say *how* those listed documents are updated.  Might
> pay to include a few works on how.
>

Thank you, that was helpful feedback.  I changed the introduction text as
follows:
OLD:
This document updates these RFCs that normatively reference TLSv1.0 or
TLSv1.1 or DTLS1.0 and have not been obsoleted.
NEW:
 This document updates the following RFCs that normatively reference
TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of these
older versions. Fallback to these versions are prohibited through this
update.

Section 2 can be cut down a lot.  The quote from another document is longer
> than the rest of the text.  In many ways, saying that the IETF is moving
> last is not a great thing to memorialize in RFC, as much as it is useful in
> an Internet-Draft or in argumentation in support of publication of the doc.
>

A bunch has been cut out already, but I propose also cutting out the
following text to address your specific point (well taken):
1st paragraph and last 2.

REMOVE:
  Industry has actively followed guidance provided by NIST and the PCI
  Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2
  should remain a minimum baseline for TLS support at this time.

  The Canadian government treasury board have also mandated that these
  old versions of TLS not be used.

  Various companies and web sites have announced plans to deprecate
  these old versions of TLS.


The title of Section 3 could be a bit clearer.
>
Proposed:
SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1

If you have a more terse suggestion, please post.  I agree this should be
more clear.


>
> It might pay to explain what RFC 7525 is in Section 6.  Why does that
> document warrant special attention over the 70-odd other ones.
>

Good point, how about the following text:

PROPOSED:
RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)", is the mpost
recent best practice document for implementing TLS and was based off of
TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not yet been
deprecated. As such, this document is called out specifically to update
text implementing the deprecation recommendations of this document.


> Otherwise, publish this.
>

Thank you!

I'll continue through the rest of the messages, but may have a delay when
tending to other responsibilities.
I am putting the proposals into a new version to upload to the git
repository.

Best regards,
Kathleen


>
>
> On Sat, Apr 13, 2019, at 09:28, 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.
> >
> > 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
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

Thanks, Gary and others for the helpful feedback and support!  I like
Stephen can look at integrating the suggestions this weekend/early next
week.  Please do keep the comments coming.

Best regards,
Kathleen

On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski  wrote:

> On 4/12/19 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.
>
> I think the document should be published.
>
> I agree with Martin Thomson's observation that the SP 800-52r2 quotes in
> Section 2 are a bit prolix considering the relatively small content that
> would remain if excised, and that NIST document has been in draft for a
> prolonged time (reducing its authority). The quotes imply but do not demand
> disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to
> mean that use of TLS 1.2 rather than TLS 1.3 is sinful.
>
> An additional (congenial) informative reference could be BSI TR-02102-2
> found at
>
>
> https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html
>
> which in §3.2 states "TLS 1.0 and TLS 1.1 are *not recommended*".
>
> Regards,
>
> Gary
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Alternative ESNI?

[Kathleen Moriarty]

Just a clarifying question inline
On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla  wrote:

>
>
> On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters  wrote:
>
>> On Fri, 14 Dec 2018, Eric Rescorla wrote:
>>
>> > However, in a large number of cases (e.g., an attacker on your local
>> network,
>> > there are non-DNSSEC ways of obtaining this property, such as using DoH.
>>
>> Data origin authenticity is not the same as transport security.
>>
>
> Yes, I'm quite aware of this fact.
>
>
> DoH offers no guarantee that the non-dnssec protected information you
>> received is not modified.
>>
>
> As with all things security, it depends on your threat model. If the
> attacker you
> are concerned with is between you and the DNS server, then in fact it does
> provide protection.
>
>
> Unfortunately, I keep needing to say this on various IETF lists. The
>> move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided
>> and just moving the goal post.
>>
>
> I don't think this is a very accurate characterization of the situation.
> At present,
> the vast majority of DNS information is not DNSSEC protected [0], and yet
> we
> have to rely on it. If there's a "blindly trusting" in this discussion,
> it's that. DNS
> over HTTPS is designed to improve the situation, though of course it's not
> a panacea.
>
> However in *this* case, it actually covers a pretty large fraction of the
> threat
> model, because (1) many attackers are close to the user and (2) if the
> attacker
> controls your DNS server, then they learn which site you are going to in
> any case even before you send SNI.
>

This is written as a pretty broad statement.  Did you intend to say that
the attackers for this threat vector are close to the user or many
attackers? Asking as this could sway opinions and the current solution is
well suited to CDNs, not necessarily others.

Even if all the attacker can do is *modify*
> records rather than observe queries, this is often enough. For censorship
> applications,
> they just serve a blackholed IP address, and for surveillance
> applications, an
> attacker with significant network capabilities can serve a dedicated IP
> for each
> server name and then forward the traffic.
>
> Note that DNSSEC does not help very much in this case. If the attacker is
> the server, they don't need to modify records, and if they are not the
> server,
> then DNSSEC protection relies upon the client hard-failing on DNSSEC
> failures,
> which generic clients do not do because it would cause unacceptable
> failure rates.
>
> -Ekr
>
> [0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf provides an
> overview
>

This is probably a bit better as a reference as it appears to be kept
current:
https://www.internetsociety.org/deploy360/dnssec/statistics/

and includes links to others providing statistics for reference as well.
The validation statistics look a bit better in the following study:
https://stats.labs.apnic.net/dnssec/XA?c=XA=1=1=1=7=0
where worldwide, they say 16% DNSSEC validates.

-Kathleen


> of the extremely depressing state of play; only 1% of .com is properly
> signed
> and about 30% of domains which have DNSSEC don't publish all the records
> needed to verify the domain.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Kathleen Moriarty]

Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> "Vulnerable-by-design ciphersuites"? Vulnerable to what? 
> 
> Suck sites are designed to provide end-point authentication and traffic 
> integrity. Care to explain/show how these properties would not hold?
> 
> Besides, it's been explained several times that some use cases do not require 
> confidentiality, and in some use cases confidentiality is forbidden.

I agree with Uri here, flexibility to cover these use cases to accommodate the 
actual security requirements may result in them using something instead of 
nothing.  It could be defined and not listed as Recommended as well.  This 
comes down to risk management and options, where the risk can be clearly 
explained and the lack of recommendation can also be explained.

Best regards,
Kathleen 

> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell  wrote:
>> 
>> 
>> 
>>> On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote:
>>> All, A couple IoT consortiums are trying to embrace the improvements
>>> made to TLS 1.3 and as they define their new security constructs
>>> would like to adopt the latest protocols, in this case TLS 1.3.   To
>>> that extent, they have a strong need for mutual authentication, but
>>> integrity only (no confidentiality) requirements.
>>> 
>>> In following the new IANA rules, we have posted the draft
>>> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
>>> to document request for registrations of HMAC based cipher selections
>>> with TLS 1.3…..and are soliciting feedback from the WG on the draft
>>> and its path forward.
>> 
>> As ekr pointed out, with the new registration rules,
>> there's nothing to stop someone defining any old set
>> of crypto stuff and getting non-recommended codepoints.
>> 
>> That said, I don't consider that defining such
>> vulnerable-by-design ciphersuites is a good plan.
>> 
>> - It imposes costs on the non-niche users of TLS - once
>> these things are defined then developers and those who
>> deploy/configure applications using TLS need to check
>> that they're not using these undesirable ciphersuites,
>> so costs are being displaced from niche uses to the
>> vast majority of implementations and deployments, which
>> seems to me to be a bad idea. And we know that people
>> will sometimes get those checks wrong leading to unexpected
>> transmission of plaintext over the Internet.
>> 
>> - Similarly, just defining such ciphersuites seems likely
>> to lead to less well tested and infrequently used code
>> paths, which is undesirable. (Assuming someone pays some
>> developer to add these to some library, which generally
>> does seem to happen.)
>> 
>> - RFC7525 [1] is clear on this topic (after debate in the
>> UTA WG) - "Implementations MUST NOT negotiate the cipher
>> suites with NULL encryption" and I see nothing new to
>> convince me that that ought change for TLS1.3.
>> 
>> - Code footprint arguments aren't that convincing to
>> me - to get interop for the few devices where AES being
>> present or absent could make a real difference, you'd
>> need an awful lot more profiling of TLS or DTLS. I don't
>> see evidence of that so the interop/footprint arguments
>> seem pretty weak. I'd also bet that any useful "tiny
>> footprint" profile of that kind would end up targeting
>> loads of use-cases where confidentiality is absolutely
>> required.
>> 
>> - (In addition to the good points made by Geoffrey
>> Keating [2]) cleartext payloads would also assist in
>> device fingerprinting, making it easier to exploit
>> vulnerabilities at scale.
>> 
>> - IIUC there is also a desire to encrypt firmware
>> updates so that patches can be distributed more quickly
>> than attackers can reverse-engineer attacks. [4] I'm
>> not entirely sure if that's really likely to happen,
>> but if it were, then devices would need to be able to
>> use recommended ciphersuites in any case.
>> 
>> - TLS/AX.25 doesn't seem that good a plan in any
>> case - according to [3], which seems reasonable to
>> me, using clear-signed GPG is quicker and better
>> meets the oddball regulations. Attempting to deal
>> with those regulations by weakening TLS seems like
>> a very bad plan, as you'd fail in any case to achieve
>> interop with normal TLS applications like the web.
>> (And the advertising is as illegal as the crypto
>> apparently, though I do like that aspect:-)
>> 
>> - WRT unix sockets, I'm not clear that there's a
>> sufficiently important performance improvement in
>> real deployments to justify introducing weakened
>> ciphersuites - presumably mail servers are going to
>> use standard TLS libraries that (I hope!) won't be
>> offering NULL encryption, so I'd be surprised if
>> the right engineering decision was to prioritise
>> CPU to that extent, given the risks associated with
>> having weak ciphersuites present in widely used
>> implementations. IOW, it seems more 

Re: [TLS] RFC 8446 on The Transport Layer Security (TLS) Protocol Version 1.3

[Kathleen Moriarty]

Congratulations to all who contributed!  In addition to EKR & the chairs, thank 
you also to Ben who assisted with all of the final checks as the responsible AD 
for this part of the process.

Kathleen 

Sent from my mobile device

> On Aug 10, 2018, at 7:56 PM, Benjamin Kaduk  wrote:
> 
> A big congratulations and thanks to Ekr, the chairs, Kathleen, and all the
> researchers and contributors who helped make this happen!
> I'm looking forward to seeing the deployment share grow as we get the final
> version out in the wild!
> 
> -Ben
> 
>> On Fri, Aug 10, 2018 at 04:54:34PM -0700, rfc-edi...@rfc-editor.org wrote:
>> A new Request for Comments is now available in online RFC libraries.
>> 
>> 
>>RFC 8446
>> 
>>Title:  The Transport Layer Security (TLS) Protocol 
>>Version 1.3 
>>Author: E. Rescorla
>>Status: Standards Track
>>Stream: IETF
>>Date:   August 2018
>>Mailbox:e...@rtfm.com
>>Pages:  160
>>Characters: 337736
>>Obsoletes:  RFC 5077, RFC 5246, RFC 6961
>>Updates:RFC 5705, RFC 6066
>> 
>>I-D Tag:draft-ietf-tls-tls13-28.txt
>> 
>>URL:https://www.rfc-editor.org/info/rfc8446
>> 
>>DOI:10.17487/RFC8446
>> 
>> This document specifies version 1.3 of the Transport Layer Security
>> (TLS) protocol.  TLS allows client/server applications to communicate
>> over the Internet in a way that is designed to prevent eavesdropping,
>> tampering, and message forgery.
>> 
>> This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,
>> 5246, and 6961.  This document also specifies new requirements for
>> TLS 1.2 implementations.
>> 
>> This document is a product of the Transport Layer Security Working Group of 
>> the IETF.
>> 
>> This is now a Proposed Standard.
>> 
>> STANDARDS TRACK: This document specifies an Internet Standards Track
>> protocol for the Internet community, and requests discussion and suggestions
>> for improvements.  Please refer to the current edition of the Official
>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
>> standardization state and status of this protocol.  Distribution of this 
>> memo is unlimited.
>> 
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>  https://www.ietf.org/mailman/listinfo/ietf-announce
>>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>> 
>> For searching the RFC series, see https://www.rfc-editor.org/search
>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>> 
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>> 
>> 
>> The RFC Editor Team
>> Association Management Solutions, LLC
>> 
> 
> ___
> 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] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Contributions with data are welcomed and encouraged.

Thank you,
Kathleen 

Sent from my mobile device

> On Jul 10, 2018, at 10:07 AM, Peter Gutmann  wrote:
> 
> nalini elkins  writes:
> 
>> It would be nice to see some of this reflected in the draft rather than only
>> statistics on browsers.   The real usage of these protocols is far more
>> complex.
> 
> +1.  It often seems that the only possible use for TLS that gets considered in
> these things is web browsers and web servers, or big-iron type servers in
> general.  There's a vast amount of TLS that never goes anywhere near a browser
> or server of this kind.  In particular, the assumptions that are no longer
> valid in this case are:
> 
> - CPU and memory is nearly unlimited and nearly free.
> 
> - Anything can be easily upgraded at the touch of a button.
> 
> - Everyone gets their certs from a commercial CA (that's present in a trust
>  database).
> 
> - People want the most full-featured, complex protocol possible.
> 
> - Users want the latest, trendiest algorithms at all times.
> 
> [Feel free to add more to this list, that's just the stuff that springs
> immediately to mind].
> 
> In the case of SCADA/embedded, pretty much the exact opposite of all of those
> points is the case (the last may be somewhat debatable, it's a reference to
> the fact that industry groups are very conservative and tend to stick with
> something that has what's regarded as good provenance).
> 
> Peter.
> 
> ___
> 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] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Hi Nalini,

I think it would be more useful to collect show stopper information.  Do they 
have systems or applications that cannot be upgraded as there is no upgrade 
path?  Do these systems or applications matter in terms of deprecation?  It may 
not matter if they are isolated or there is no external requirement around 
encryption.

I did hear from someone off-list that I think will submit a PR on the systems 
he can’t upgrade, but he also said they don’t matter and are not a show stopper.

Thank you,
Kathleen 

Sent from my mobile device

> On Jul 11, 2018, at 5:50 AM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
>> On 11/07/18 06:45, nalini elkins wrote:
>> Stephen,
>> 
>>> I'd love to add more detail like that and/or more sections for other
>> protocols if folks have data to offer with references.
>> 
>> I believe that I can reach out to various people I know.   Please comment
>> if my methodology is acceptable and if you think this will be helpful.
> 
> It's not whether the methodology is acceptable to me or not
> but whether or not the references to the numbers are credible
> for readers:-)
> 
> A few comment below,
> 
>> 
>> I am thinking the following:
>> 
>> Location: U.S. / Canada (possibly U.K.)
>> 
>> -  3 banks (hopefully from the top 5)
>> -  3 large insurance companies  (includes back end processing)
>> -  3 U.S. federal government agencies
>> -  3 companies in the Wall Street / Stock brokerage sector (includes back
>> end processing)
>> -  3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.)
>> -  3 in the retail sector (Home Depot, Target, Lowes, et al)
> 
> Those are pretty small numbers unless they're interacting with
> a lot of TLS services. It'd be hard to know if they'd be
> representative of something or not if they're anonymised in the
> results. I'd encourage you to try get people to be open about
> things here - there's no particular shame in having 10% TLSv1.0
> sessions after all:-)
> 
>> 
>> Note: I put in "back end processing" because these are the folks that most
>> often have many connections to other business partners and so in some ways
>> have the most complex systems to deal with.
>> 
>> Note #2:  This is aspirational!  I hope I can get all these people to
>> cooperate.  I will try at least to get some in each category.
>> 
>> 
>> I will ask them the following questions:
>> 
>> 1.  How many applications do you have?  (This may end up being only the
>> mission critical ones as otherwise it may be too hard to obtain.)
> 
> I'm not sure that's so interesting for this question. And I'm not
> sure that different people would count things as applications in
> the same way.
> 
>> 2.   How many are using TLS and how many are still plain text?  (We will
>> disregard SSH and other such variants.)
> 
> Again, that's not so interesting here.
> 
>> 3.   What percent of clients are using a pre-TLS1.2 version?  (This will be
>> an estimation.
> I don't see why this needs to be estimated, this is kinda the key
> measurement needed and easy to measure. There should be no need for
> anyone to stick their thumb in the air for this:-)
> 
> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
> figures apply.
> 
> And of course providing as much context as possible so that it's
> possible to understand the numbers and whether or not the numbers
> from different sources are based on the same or different kinds of
> measurement.
> 
>> 
>> 4.   Do you have an active project to migrate off of older versions of TLS?
> 
> Sure.
> 
>> 
>> 5.   What do you estimate your percent of clients using pre-TLS1.2 versions
>> to be next year?
> 
> I don't see how this'd be so useful. Aaking about the historic and
> current rates of change of use of the various protocol versions would
> be good though if people have that, but they may not.
> 
> S.
> 
>> 
>> 
>> Please let me know if this will be of use & if you have suggestions for
>> improvement.
>> 
>> Thanks,
>> Nalini
>> 
>> 
>> 
>> 
>> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell 
>> wrote:
>> 
>>> 
>>> Hi Nalini,
>>> 
 On 10/07/18 04:50, nalini elkins wrote:
 It would be nice to see some of this reflected in the draft rather than
 only statistics on browsers.   The real usage of these protocols is far
 more complex.
>>> 
>>> I didn't have time before the I-D cutoff but have since
>>> added a section on mail to the repo pre-01 version. (See
>>> [1] section 3.2.) I'd love to add more detail like that
>>> and/or more sections for other protocols if folks have
>>> data to offer with references.
>>> 
>>> Consistent with other folks' numbers sent to the list
>>> yesterday, (though based on a much smaller sat of data I
>>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>>> IP addresses that listen on port 25 (mail servers).
>>> 
>>> What I don't currently have is a rate of 

Re: [TLS] [CAUTION] Re: Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 10, 2018, at 4:31 PM, Martin Rex  wrote:
> 
> m...@sap.com (Martin Rex) wrote:
>> Andrei Popov  wrote:
>>> 
>>> On the recent Windows versions, TLS 1.0 is negotiated more than 10%
>>> of the time on the client side (this includes non-browser connections
>>> from all sorts of apps, some hard-coding TLS versions),
>>> and TLS 1.1 accounts for ~0.3% of client connections.
>> 
>> "On recent Windows versions" sounds like figure might not account
>> for Windows 7 and Windows Server 2008R2, about half of the installed
>> base of Windows, and where the numbers are likely *MUCH* higher.
>> 
>> When troubleshooting TLS handshake failures, I sometimes trying
>> alternative SSL/TLS clients on customer machines through remote support,
>> and it seems when I run this command on a Windows 2012R2 server:
>> 
>>powershell "$web=New-Object System.Net.WebClient ; 
>> $web.DownloadString('https://www.example.com/')" 2>&1
>> 
>> it connects with TLSv1.0 only, and this is a client-side limitation.
>> 
>> To make it use TLSv1.2, I would have to use
>> 
>>powershell "[Net.ServicePointManager]::SecurityProtocol = 
>> [Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; 
>> $web.DownloadString('https://www.example.com/')" 2>&1
>> 
>> i.e. explicit opt-in.
> 
> 
> btw. I checked this on a Windows 10 (1709) machine, and it's powershell also
> tries connecting with TLSv1.0 only.
> 
> To me, it looks more like 100% of the Microsoft Windows installed
> base not being ready for a TLSv1.2-only world.
> 
Martin,

Do you want to add a PR with this unless further verification is needed?

Thank you,
Kathleen 

> 
> -Martin
> 
> ___
> 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] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
as a baseline.  Applications other than those using HTTP may not have
had the same reduction in usage.  If you are responsible for services
where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.  We've received some feedback that has been incorporated
into the working draft and feelers in general have been positive.  It
would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-diediedie

Thanks in advance,
Kathleen


-- Forwarded message --
From:  
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell , Kathleen Moriarty




A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:   draft-moriarty-tls-oldversions-diediedie
Revision:   00
Title:  Deprecating TLSv1.0 and TLSv1.1
Document date:  2018-06-18
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
Status:
https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
   This document [if approved] formally deprecates Transport Layer
   Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
   these documents to the historic state.  These versions lack support
   for current and recommended cipher suites, and various government and
   industry profiiles of applications using TLS now mandate avoiding
   these old TLS versions.  TLSv1.2 has been the recommended version for
   IETF protocols since 2008, providing sufficient time to transition
   away from older versions.  Products having to support older versions
   increase the attack surface unnecessarily and increase opportunities
   for misconfigurations.  Supporting these older versions also requires
   additional effort for library and product maintenance.

   This document updates the backward compatibility sections of TLS RFCs
   [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
   document also updates RFC 7525.




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



-- 

Best regards,
Kathleen

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

Re: [TLS] DNS-based Encrypted SNI

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 4, 2018, at 2:20 PM, Eric Rescorla  wrote:
> 
> Hi Kathleen,
> 
>> On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty 
>>  wrote:
>> I’m also fine with the work going forward, however it was only in March that 
>> EKR assured people concerned that they don’t need to worry about SNI being 
>> encrypted repeating similar statements previously made to the same effect.  
>> Meantime, he was working on such a solution. 
> 
> This is not really correct. As of March, I had basically given up on how to 
> do ESNI in TLS the near future and wasn't really working on it [0] and then 
> in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I 
> realized that the proposal in this document could work.
> 
> Moreover, I think I've been pretty clear that I wanted to do ESNI and it was 
> just that we didn't know how. For instance, here's what I said in PATIENT:
> 
>My evaluation of the current state of SNI encryption is that given the
>current technical state, it will not see particularly wide deployment, with
>the primary scenario being "at-risk" sites who are subject to censorship 
> who
>either hide behind or co-tenant with sites which are not subject to
>censorship. That probably isn't going to be incredibly common right now.. 
> Of
>course, this is regrettable from the perspective of people designing these
>protocols, but I think that's the situation.
> 
> As I said the other day, predictions are hard, especially about the future, 
> and this turns out not to have been totally right (though I also don't think 
> it's really accurate to characterize it as my saying that people don't need 
> to worry). I'm sorry if people people are surprised now. That wasn't my 
> intent, but as I said above, I was surprised too!
> 

Well, the messages on the Effects of Pervasive Encryption for Operators also 
factored into my response.  You wanted that text removed and we refused 
(rightly so).  You also had someone write a blog to have a reference that 
talked about it’s wide deployment.  The perception is from multiple 
interactions and I favor transparency.

Best,
Kathleen 

> -Ekr
> 
> [0] Just to be completely clear, there was and is ongoing work on protecting 
> SNI via HTTP connection coalescence (see Mike Bishop's presentation in 
> London), but that's a different flavor of approach, and it's not like it's 
> any secret it's happening.
> 
> 
>  
>> Kathleen 
>> 
>> > 
>> > Cheers,
>> > S.
>> > 
>> > 
>> >> 
>> >> -Ekr
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >> 
>> > <0x5AB2FAF17B172BEA.asc>
>> > ___
>> > 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] DNS-based Encrypted SNI

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 4, 2018, at 9:01 AM, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
>> On 03/07/18 00:39, Eric Rescorla wrote:
>> Hi folks,
>> 
>> I just submitted:
>> 
>>  https://tools.ietf.org/html/draft-rescorla-tls-esni-00
> 
> Thanks for writing that up. I think it's an interesting
> addition to the set of potential solutions.
> 
>> 
>> This draft describes a DNS-based approach to doing encrypted SNI.
>> 
>> Previously, we had thought this wouldn't work because only sites that
>> were particularly vulnerable would do it, and so the use of ESNI marks
>> you out. The idea behind this draft is that there are a lot of sites
>> which are hosted by -- and whose DNS is run by -- a large provider,
>> and that provider can shift many if not all of its sites to ESNI at
>> once, thus removing the "standing out" issue and making a DNS-based
>> approach practical.
> 
> I'm not sure I fully understand how this approach would fit
> with others, nor to what extent it depends on the DNS and
> CDN providers co-operating, but it definitely seems worth
> exploring.
> 
>> 
>> I am working on an implementation for NSS/Firefox and I know some
>> others are working on their own implementations, so hopefully we can
>> do some interop in Montreal.
>> 
>> This is at a pretty early stage, so comments, questions, defect
>> reports welcome.
> 
> Quick comments after flicking through the draft:
> 
> - I'm not that fussed myself as to whether this uses a TXT
> or new RRTYPE. But if the latter would work, it seems better.
> 
> - I didn't quite get what "all the domains" in 3.2 means. I
> guess if a client uses non-encrypted sni for one of those,
> it should still work, but I'm not clear if supporting esni
> for any domain means that the provider has to decrypt esni
> and then deal with successful decrypted sni values as if
> the client had sent sni in clear. A concern is requiring
> "all the domains" might make it hard to roll this out.
> 
> - I guess some form(s) of key rollover will be needed, ut
> I'm not sure that not_before/not_after is the best way to
> do that.
> 
> - The ESNIKeys structure generally seems a bit complicated,
> it might be better to aim for simplifying that and maybe
> making it more "zonefile friendly" (whether in a TXT RR
> or not).
> 
> - It might be interesting to think about how this'd work
> for e.g. the IETF web site (where ietf.org is hosted
> locally but www.ietf.org is not), and for STARTTLS and
> MX RRs. That's probably ok, but I've not gotten it
> straight in my little head yet:-)
> 
> - Would it make sense to include the innocuous dummy sni
> in the published RR, so that all clients use the same
> one and stand out that bit less?
> 
> - 7.1 probably needs more work - I'm not sure that it's
> that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
> or a client application that knows the ESNIKeys, are most
> likely needed, but there's probably also some work to do
> to analyse the recursive to authoritative interactions to
> get the ESNIKeys even with DPRIVE.
> 
> Lastly, the topic of whether or not to try address this
> problem is something that the WG has debated quite a bit,
> and IIRC the consensus after that debate was to do work
> on this (hence Christian's draft).
> 
> So I don't see any need to debate whether or not to work on
> this is needed, and trying to re-open such a debate seems
> somewhat disruptive to me. It is entirely reasonable to
> consider what, if anything, widespread use of esni or other
> approaches might break though. But going back to all this
> "privacy at any cost" and "we're the enterprises" hyperbole
> is not at all helpful IMO, so I hope we don't have to suffer
> more rounds of that. But maybe that's inevitable with every
> iteration of attempts to improve privacy sadly;-(

I’m also fine with the work going forward, however it was only in March that 
EKR assured people concerned that they don’t need to worry about SNI being 
encrypted repeating similar statements previously made to the same effect.  
Meantime, he was working on such a solution.  People need warning to prepare 
for changes, not to be surprised by them after being told not to worry.  They 
may not have had a chance to think through how they might adapt.

Kathleen 

> 
> Cheers,
> S.
> 
> 
>> 
>> -Ekr
>> 
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> <0x5AB2FAF17B172BEA.asc>
> ___
> 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] Encrypted SNI

[Kathleen Moriarty]

On Tue, Jul 3, 2018 at 3:49 PM, Benjamin Kaduk
 wrote:
> On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote:
>> From a discussion on the PATIENT list found here: 
>> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html 
>> <https://www.ietf.org/mail-archive/web/patient/current/msg00078.html>
>>
>>
>> From my personal perspective, we need to be careful with all of these 
>> efforts. It feels like the pendulum has swung so far to one side, the side 
>> of privacy-at-any-cost, that we are unknowingly increasing the risk to 
>> individuals and organizations by enabling threat actors and intrusions sets 
>> to attack networks and clients without any level of protection from the 
>> network.
>
> BCP 61 leads us to not expect any protection from the network, does it not?
>
>> It also feels like a lot of these initiatives are being done without 
>> adequately involving and ensuring that enterprise networks and critical 
>> infrastructure can work with these changes. Question, do we know how these 
>> ideas and changes are going to impact an organizations ability to fulfill 
>> their requirements for regulatory compliance?
>>
>> If we continue down these paths, then I fear networks will be required to 
>> wrap all traffic in some other less secure protocol, outright deny some of 
>> these protocols, or be forced to fully proxy all traffic or take an approach 
>> that Google has done with their BeyondCorp design.
>
> I suspect you will find that many proponents of the proposals you find
> worrisome would also be enthusiastic proponents of "an approach similar to 
> what
> Google has done with BeyondCorp".  Such a discussion would be off-topic for
> the TLS list, but you would probably be well-served to have some supporting 
> text
> for why this sort of approach should be considered bad, if you want to gain
> sympathy for your perspective.

The proposal came from an AD who just a few moths ago told them not to
worry about these possible changes (see referenced thread on PATIENT
list) that impact their work, so in other words, don't prepare for it,
don't worry about alternate solutions or figuring out ways to better
articulate your use cases.  Then that AD submits the proposal.
Challenging comments are posted and I would expect that there be
sensitivities as to the origin of the draft and making it even more
fair for list participants to comment and understand that this draft
should be treated as any other.

While I agree that additional text and supporting use case information
is needed, there also needs to be an openness to listen to all views
on a proposal.  If there are use cases that are critical for SNI, they
need to surface and be considered.

Best regards,
Kathleen

>
> -Ben
>
>> The IETF work needs to do more outreach with enterprise networks and 
>> critical infrastructure and be fundamentally more inclusive. 
>> Privacy-at-any-cost is not a holistic design.
>>
>> Thanks,
>> Bret
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can 
>> not be unscrambled is an egg."
>>
>>
>>
>> ### Copied content from the PATIENT discussion 
>>
>>
>> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty > gmail.com <mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > <mailto:ekr%20at%20rtfm.com>> wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
>> > wrote:
>> >>
>> >> Your point is one that deserves further discussion, Eric - which seems
>> >> likely to scale rapidly going forward.  It is key.
>> >>
>> >> So how does draft-ietf-tls-sni-encryption it into the argument?
>> >
>> >
>> > As you suggest, SNI encryption is intended to conceal the SNI, which of
>> > course would make SNI inspection difficult.
>> >
>> > My evaluation of the current state of SNI encryption is that given the
>> > current technical state, it will not see particularly wide deployment, with
>> > the primary scenario being "at-risk" sites who are subject to censorship 
>> > who
>> > either hide behind or co-tenant with sites which are not subject to
>> > censorship. That probably isn't going to be incredibly common right now. Of
>> > course, this is regrettable from the perspective of people designing these
>> > protocols, but I think that's the situation.
>>
>> EKR posted a draft to encrypt SNI, see:

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

[Kathleen Moriarty]

Hi Christian,

Thanks for including text on the known uses of SNI.  Hopefully if
there are other known uses, they will be contributed for evaluation of
this problem space.

In section 2.2, enterprises can still use proxy based or active
interception solutions to enable inspection of traffic on their
network.  I suspect that will be the method of choice over the
endpoint for some time to come.  I also don't think it would be
universally accepted that enterprise interception, where they have
agreements from users to monitor (employment agreements - common in US
and EU, with Germany being an exception here as apparently they have a
law for users to have an expectation of privacy when doing personal
business from the work place), should be classified as an 'attack'.  I
think rephrasing for that use case would be helpful for the neutrality
of the document.

Section 3.8.1 - TLSv1.3 already encrypts the ALPN response via
EncryptedExtensions.  Is this argument for TLSv1.2?  The response is
where the answer on the negotiated protocol is provided and it's
already hidden, so I'm not clear on why this is here except if it is
for earlier versions.  This draft just says hide the ALPN, are you
concerned about the request too with the list of possible protocols?

Thanks,
Kathleen

On Wed, May 23, 2018 at 10:49 AM, Sean Turner  wrote:
>
>
>> On May 23, 2018, at 10:38, Ben Schwartz 

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Kathleen Moriarty]

Hi Tobias,

If you use search terms that include pkix, authorization, access control, and 
attribute certificate profile, you’ll find a few documents.  This one should be 
helpful based on your description:

https://tools.ietf.org/html/rfc5755

Best regards,
Kathleen 

Sent from my mobile device

> On Apr 16, 2018, at 4:55 AM, Eric Rescorla  wrote:
> 
> I am not aware of anywhere this is documented, primarily because it's so 
> application-specifiic.
> 
> -Ekr
> 
> 
>> On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom  
>> wrote:
>> Hi dear TLS experts,
>> 
>>  
>> 
>> Apologies for my stupid question for advise:
>> 
>> I am currently working on some design requirements for mutual authentication 
>> and have a question regarding verification of client certificate.
>> 
>>  
>> 
>> In many web scenarios the simple use is server authentication by certificate 
>> and verification of client id by username & password or by a simple 
>> verification of client certificate.
>> 
>>  
>> 
>> Are there any RFCs that speak (beyond the general verification of the 
>> certificate in mutual TLS authentication) to the need to also verify the CN 
>> inside the client certificate against an additional whitelist _before_ 
>> establishing a TLS connection.
>> 
>>  
>> 
>> For example in this scenario:
>> 
>> A client with a valid certificate may be allowed to connect to application 
>> 1, but would not be allowed to connect to application 2. (for sake of 
>> separation application 1 and 2 are on separate servers (application 1 on 
>> server 1 and application 2 on server 2).)
>> 
>>  
>> 
>> From my current understanding, I would establish the TLS connection in both 
>> cases, do mutual authentication and then let application 2 reject access 
>> based on that the user is not allowed to access it. There is a question 
>> whether this would expose to a risk that server resources could be exhausted 
>> by allowing to establish the TLS connection before failing, but this does 
>> not seem too bad to me. But maybe I am missing something…
>> 
>>  
>> 
>> Are there any informational (or standard) RFCs for TLS that speak about this 
>> risk and best practices to address it?  
>> 
>> (e.g. using additional whitelist checks of parameters inside the client 
>> certificate for access control checks already during phase of establishing 
>> the TLS connection)
>> 
>>  
>> 
>> Thank you and sorry for bothering, Tobias
>> 
>>  
>> 
>> 
>> ___
>> 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Kathleen Moriarty]

There's a few steps Paul is missing in his summary of the process.

On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes  wrote:
>
>
> On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters  wrote:
>>
>> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>>
>>> I don't really agree with that characterization.  To state my
>>> understanding,
>>> as responsible AD, of the status of this document: this document is in
>>> the
>>> RFC Editor's queue being processed.
>>
>>
>> That was a process mistake.
>>
>> 1) ekr filed a DISCUSS
>> 2) other people raised issues in response
>> 3) ekr's DISCUSS was resolved but not the other people's concern

The concerns were discussed at the meeting in London.  The chairs
reviewed 3 separate issues.  The first was agreed upon that a simple
wording change that was not significant to hold up for approval was
made.  No change was needed with one of the other issues.  With the
third, the room was in full agreement that this should be done in a
separate draft.  I went to the mic and summarized this and asked for
agreement that it was ok to approve the document as a result and there
was no opposition, just agreement.

It was right of the chairs to put this back out to the list for
confirmation as they have the ability to pull a document back if they
decide that is the right course of action.

The AD can also override the chairs if they decide it should go
forward and the AD does not agree (although I don't see that in his
messages).

Best regards,
Kathleen

>> 4) document was placed in RFC Editor queue despite this
>> 5) TLS consensus call done on the list
>> 6) here we are
>>
>> I think it is not good to use this process as a way of approving things.
>> A process mistake was made.
>
>
> The question Ben was asking, though, is whether the impact of that process
> mistake is serious enough to merit pulling back the doc from the RFC editor.
>
> Personally, I think the answer is no, and I'm not hearing clear consensus in
> either direction in this thread.  So ISTM the best information the chairs
> and ADs have to go on is the hum taken in the room (which all of the
> litigants here participated in), which was pretty clearly in favor of
> proceeding.
>
> --Richard
>
>>
>>
>> Paul
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Kathleen Moriarty]

Sent from my mobile device

> On Mar 30, 2018, at 5:20 PM, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> TLS 1.3 has been approved by the IESG and it's on its way to the RFC Editor, 
> so 
> I don't really see this changing any time soon for the base RFC.
> 
> I think there's some debate about whether this is a good idea, but in any 
> case,
> the right way to pursue it would be to publish a new draft, presumably with
> some extension that says "I speak extended alerts".
> 
I agree with Eric’s assessment, this could be in a new draft as an extension.

Kathleen 

> -Ekr
> 
> 
> 
> 
>> On Fri, Mar 30, 2018 at 1:55 PM, Bill Frantz  wrote:
>> On 3/30/18 at 7:35 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:
>> 
>>> As you mention, debugging TLS is unnecessarily painful if there's a problem,
>>> you typically just get a handshake-failed alert which is essentially no
>>> information at all.  Having a debug-mode capability to send back a long-form
>>> error message would be extremely useful, maybe an extension to say "send 
>>> back
>>> a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it"
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Kathleen Moriarty]

The document has been approved for publication and the outstanding
reference will be added in the RFC editor process during Auth48.

Thank you all for your work on this protocol.

Best regards,
Kathleen

On Tue, Mar 20, 2018 at 5:21 PM, Eric Rescorla  wrote:
>
>
> On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario  wrote:
>>
>> On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
>> > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos
>> > 
>> >
>> > wrote:
>> > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
>> > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
>> > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
>> > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
>> > > > > > ...
>> > > > > >
>> > > > > > > we do not have a reliable mechanism of differentiating between
>> > > > > > > external and
>> > > > > > > resumption PSKs while parsing Client Hello
>> > > > > >
>> > > > > > Well, a valid external PSK (identity) the server will of course
>> > > > > > recognize, and we have a SHOULD-level requirement that the
>> > > > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
>> > > > > > gotten
>> > > > > > to think through whether there is still potential for
>> > > > > > information
>> > > > > > leakage about external PSK identities, but it seems like there
>> > > > > > would
>> > > > > > not be, provided that the server prefers resumption to external-
>> > > > > > PSK
>> > > > > > full handshakes.
>> > > > >
>> > > > > I am concerned with the privacy issues linked to these "external
>> > > > > PSK
>> > > > > identities". If a system is set so that clients use static PSK
>> > > > > identities, then the identity is an identifier and the client's
>> > > > > movements and connections can be tracked. I don't think privacy is
>> > > > > improved if we make it easy to differentiate external identities
>> > > > > from
>> > > > > resumption tickets.
>> > > >
>> > > > Oh, of course, the privacy considerations of the current external
>> > > > PSK scheme are terrible!  This follows naturally from external PSKs
>> > > > having not really been a first-class citizen while we were designing
>> > > > things; we stuffed resumption PSKs together with external PSKs for
>> > > > the convenience of having them use the same binder construct and
>> > > > only needing to have one extension at the end of the ClientHello.
>> > > > Resumption flows get single-use tickets for privacy preservation,
>> > > > and external PSKs get infinite use and a gigantic correlation
>> > > > channel.
>> > >
>> > > I agree.
>> > >
>> > > > > If you want to use PSK with some level of privacy, you might adopt
>> > > > > a
>> > > > > different setup. For example, servers could provision the clients
>> > > > > with a
>> > > > > set of single-use external PSK identities. But then, that looks a
>> > > > > lot
>> > > > > like resumption. Or, clients could generate single-use external
>> > > > > PSK
>> > > > > identities by encrypting their long term identity and a nonce with
>> > > > > the
>> > > > > public key of the server, a design which of course has its own set
>> > > > > of
>> > > > > issues.
>> > > >
>> > > > But, as you note, this is something of an open problem for how to do
>> > > > well, and this document is already approved by the IESG.  (It's also
>> > > > not entirely clear that the TLS WG would be the best place to design
>> > > > this sort of scheme, though of course it could choose to do so.)
>> > > >
>> > > > So to me the open question is whether we consider enumeration of
>> > > > external PSK identifiers to be something we can address reasonably
>> > > > at this stage of the document's lifecycle at all.  (I also note that
>> > > > the presence of a CVE number for a similar issue does not
>> > > > necessarily mean anything -- CVE assignments can occur for
>> > > > situations with no actual security impact and/or against the wishes
>> > > > of the software authors.)  I don't think anyone has proposed a
>> > > > minimal change that would close the enumeration channel, and given
>> > > > that external PSKs already have bad privacy properties, it seems
>> > > > like we may just have to accept this state of affairs for this
>> > > > document.
>> > >
>> > > That's a good general remark, but not really the case for the
>> > > vulnerabilities that Hubert pointed out.
>> > >
>> > > > Hubert also says:
>> > > >
>> > > > % so there's no reliable way to say that, yes, this identity is or
>> > > > is
>> > > > not a
>> > > > % resumption ticket, if I can't decrypt it
>> > > >
>> > > > Mostly.  External PSKs are established out of band, and that
>> > > > provisioning process *could* include knowledge that the
>> > > > obfuscated_ticket_age would always be zero when those PSKs are in
>> > > > use, and that would be reliable for those specific parties.
>> > >
>> > > I believe that this can happen in an interoperable way if the 

Re: [TLS] Breaking into TLS to protect customers

[Kathleen Moriarty]

On Thu, Mar 15, 2018 at 12:58 PM, Carl Mehner <c...@cem.me> wrote:
>
>
> On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>> I think what Yoav is referring to by detecting BOTS within the
>> network, is really so called advance persistent threat (APT) actors
>> that are moving around the internal network leveraging existing access
>> rights of compromised accounts and privilege escalation
>> vulnerabilities.  These might be detectable with 'visibility'.
>> Patterns and behavior might be used to detect the APT use case whether
>> or not encryption protects the stream, but it is more difficult.
>
> Yes, they might, however, the best place for malware detection is on the
> edge (which is out of scope for "in the Datacenter" type connections) and
> the endpoint, where an agent is able to run that does not need to 'break in'
> to the TLS session. Yes, the Fenter draft talks about how malware endpoints
> can be anywhere in the network, and that they can delete logs as a reason to
> require out of band network decryption. However, if "breaking TLS" becomes
> an effective malware mitigation means, more malware makers may move to using
> app-level encryption (as some already have). Therefore, the conclusion we
> can draw is that malware is not a reasonable reason requiring this enhanced
> "visibility".

The example I provided is not about malware, it was about lateral
movement by threat actors within a network.  The initial compromise
that led to access within the network may have been through malware or
some other vulnerability, but I do think monitoring on an internal
network (encrypted or not, through logs or on the wire) is the use
case for attack detection that is plausible with the proposed
approach.

Best regards,
Kathleen

>
>
> -carl



-- 

Best regards,
Kathleen

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

Re: [TLS] Breaking into TLS to protect customers

[Kathleen Moriarty]

On Thu, Mar 15, 2018 at 4:53 AM, Ion Larranaga Azcue  wrote:
> I fail to see how the current draft can be used to provide visibility to an
> IPS system in order to detect bots that are inside the bank…
>
>

In an effort to help clear up the use case and not weighing in on the
discussion...

I think what Yoav is referring to by detecting BOTS within the
network, is really so called advance persistent threat (APT) actors
that are moving around the internal network leveraging existing access
rights of compromised accounts and privilege escalation
vulnerabilities.  These might be detectable with 'visibility'.
Patterns and behavior might be used to detect the APT use case whether
or not encryption protects the stream, but it is more difficult.

If an attacker was using their own server and the fingerprints were
different, detection with encryption would be possible even if it is
more difficult. Threat sharing groups do exchange detection techniques
that involve encrypted traffic for the latter case.  And I think
everyone agrees, that this is not a use case the proponents are trying
to cover.

Best,
Kathleen

>
> On the one hand, the bot would never opt-in for visibility if it’s trying to
> exfiltrate data, so this capability would never get activated. And even if
> the bot was nice enough as to opt-in for visibility, the party responsible
> for providing the IPS with the required information is the server, which in
> this case is under control of the attacker. There is no way the attacker’s
> server will negotiate with the IPS the required keys to decrypt the channel
> (most likely it can’t even communicate with it).
>
>
>
> And if you decide to close that connection because of the lack of
> visibility, well… 99% of TLS servers in internet will not negotiate
> visibility keys with your specific IPS, so you could as well close all TLS
> traffic going outside. And you don’t need visibility for this, only a
> well-configured firewall.
>
>
>
> So, maybe I’m wrong, but I think that this specific use case (analysis of
> either malicious or legitimate clients’ traffic going from the enterprise
> network to outside servers) is not covered by the draft under discussion
> because the remote server will never negotiate the encryption keys with the
> IPS. For me, the only way to provide visibility within this case is by
> actively proxying every connection, something that proponents of the need
> for visibility don’t seem to be comfortable with, and which in my opinion
> does not require lowering the TLS protocol security level.
>
>
>
> Or maybe I misunderstood the use case altogether…
>
>
>
>
>
> De: TLS [mailto:tls-boun...@ietf.org] En nombre de Yoav Nir
> Enviado el: jueves, 15 de marzo de 2018 5:58
> Para: Rich Salz 
> CC: tls@ietf.org
> Asunto: Re: [TLS] Breaking into TLS to protect customers
>
>
>
> Hi, Rich.
>
>
>
> You are conflating customers and users. The customer that may be protected
> by breaking TLS in a bank’s server farm is the bank itself. An IPS system
> with visibility into the traffic may detect bots that are there to steal
> data or mine cryptocurrencies or whatever.
>
>
>
> If the customers of the bank are protected, it’s a happy side effect
> (collateral benefit?). The object is to protect the system integrity and the
> data.
>
>
>
> Yoav
>
>
>
> On 15 Mar 2018, at 5:29, Salz, Rich  wrote:
>
>
>
> Some on this list have said that they need to break into TLS in order to
> protect customers.
>
>
>
> The thing customers seem to need the most protection is having their
> personal data stolen.  It seems to happen with amazing and disappointing
> regularity on astounding scales.  Some examples include
>
> · retailer Target, presumably subject to PCI-DSS rules
>
> · Anthem health insurance, presumably a regulated industry
>
> · Equifax, a financial-business organization (but apparently not
> regulated)
>
> · Yahoo, a company created on and by and for the Internet (one would
> think they know better)
>
> We could, of course, go on and on and on.
>
>
>
> NONE of those organizations are using TLS 1.3.
>
>
>
> So what kind of “protect the customer” requires breaking TLS?  And what
> benefits and increased protection will customers see?
>
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Kathleen Moriarty]

Clarifying question

On Tue, Mar 13, 2018 at 10:55 PM, Russ Housley  wrote:
> Ted:
>
> I do not follow.
>
> This is a bogus argument.
>
>
> I'm pretty sure there's a Monty Python skit about this, so I won't belabor
> the point.
>
>
> I'll avoid asking how many sparrows are needed ;-)
>
> First, staying with an old protocol version often leads to locking in
> unmaintained versions of old software.
>
>
> Right, that's one of the stated goals of this work: to be able to continue
> to use software that the operator can't upgrade.
>
>
> No, the enterprise wants to use maintained server implementations.
>
> Second, using TLS1.2 does not technically address the issue.  If the client
> were to exclusively offer DHE-based ciphersuites, then the visibility
> techniques that have been used in the past are thwarted.
>
>
> The client in this case is under the control of the operator, so this is a
> non-issue.
>
>
> In some cases, the client in the load balancer is under the control of the
> enterprise.  In other cases, the client is in the customer browser, and
> opt-in is very significant.

When you say customer browser, do you mean the users on the enterprise
network behind the firewall, all within the control of the enterprise
that owns the data?  I think this is what is meant since the Internet
sessions from customers could be terminated at a load balancer on the
enterprise edge and then this extension may be used between servers
internal to the enterprise and from what you are saying, browsers as
well.  Or is the plan for this to be opt-in from the customer external
to the enterprise (I didn't think that was the case and it would be
good to clarify).  This distinction would be helpful to know where
traffic may be intercepted if there were another party that might be
malicious.

Thanks,
Kathleen

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



-- 

Best regards,
Kathleen

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

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Kathleen Moriarty]

On Tue, Mar 13, 2018 at 3:08 PM, Melinda Shore
<melinda.sh...@nomountain.net> wrote:
> On 3/13/18 10:44 AM, Kathleen Moriarty wrote:
>> And then there are other options too, like another WG.  Even from
>> Stephen's list of who is in agreement with him, I've received a few
>> messages saying their text wasn't what he thinks it was.  More
>> discussion here would be good to figure out a way forward.  The chairs
>> have not agreed to allow the work to go forward, but just the
>> discussions to determine next steps.
>
> Part of the problem here, I think, is that it's not clear
> what's under discussion - the general problem or this
> specific draft.  I tend to think that discussions of the
> general problem will probably be unproductive and
> polarizing, and that if there is a way forward on this
> it's to have credible and specific technical proposals.
> Remember that in terms of process we don't need to have
> unanimity on a decision, but all serious technical
> objections need to be addressed and resolved.  So,
> if someone has a draft that can eventually clear that
> bar, proponents of allowing third parties to decrypt
> TLS sessions have a way forward.  (Unfortunately I
> don't think this draft can make it through).  At any
> rate I would regret (a lot) seeing discussion meander
> on over to the broader should-we-or-shouldn't-we question.

I think the chairs made it clear that it is on the specific draft and
they just have 10 minutes to present.  I believe the slides are
already posted and include the use cases within them.  We've all spent
way more than 10 in this discussion ;-)

It's up to the WG to decide and it seems a few want to discuss it,
even from the list that Stephen says are not interested.  I think it's
better to let the discussion happen.

Best,
Kathleen

>
> Melinda
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
>



-- 

Best regards,
Kathleen

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

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Kathleen Moriarty]

On Tue, Mar 13, 2018 at 1:21 PM, Melinda Shore
 wrote:
> On 3/13/18 6:48 AM, Jim Reid wrote:
>> Stephen, the opposite PoV is equally valid. There was no consensus in
>> Prague NOT to work on the topic. The mood of the room was evenly
>> divided.
>
> To clarify, this isn't voting.  If there's no agreement in
> either direction there's no agreement (and I hope the default
> in the IETF is not that in the absence of agreement, work
> goes forward).  The problem is how to come to agreement, and
> what that typically involves is refining the proposal to
> address objections.

And then there are other options too, like another WG.  Even from
Stephen's list of who is in agreement with him, I've received a few
messages saying their text wasn't what he thinks it was.  More
discussion here would be good to figure out a way forward.  The chairs
have not agreed to allow the work to go forward, but just the
discussions to determine next steps.

>
>> IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to
>> drop that draft and come back with a new one which would hopefully be
>> more likely to get WG consensus. That draft has now arrived. It’s
>> unreasonable to deny the new I-D a fair hearing and even worse to
>> reject it out of hand.
>
> It's surprising that it got agenda time without mailing list
> discussion.  Aside from the changes to the key
> exchange there are some clear usability problems.  While
> usability usually lies outside the purview of the IETF's
> technical work, in this case the work is premised on the
> ability of the user to consent (or not) to sharing keying
> material with a third party, which in turn suggests that
> they're presented with the question at the time the
> session is initiated, so that the extension isn't sent in
> the ClientHello.  Sounds like a click-through problem,
> tbh, where the user has little practical control over whether
> or not their data are shared with a third party.

This should have had discussion time in Singapore, as the chairs
mentioned.  I'm mostly responding though because their use cases are
entirely server-to-server from what I understand.  The client
connection to the enterprise can terminate at the network edge, then
anything within the enterprise is from another encrypted session
(which could be TLS 1.2 or another protocol, or this proposal, or
something else including methods that eliminate the architectural
design for monitoring on the wire within the datacenter).  If there
were a way to limit this extension to server-to-server, that would
eliminate the click through problem you mention and the server admin
would be aware on either end of this usage.  I don't know if there is
a way to do this without using another protocol, but making the use
case clear may help with ideas.

Best,
Kathleen

>
> Melinda
>
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Kathleen Moriarty]

Hello, Stephen.

On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
 wrote:
>
> Hi Joe,
>
> I'm sorry, but I gotta say that answer seems to me both unresponsive
> to the questions asked and unconvincing.
>
> On 08/03/18 23:08, Joseph Salowey wrote:
>> Hi Stephen,
>>
>> In the meeting in Prague there was interest in this problem space, but
>> neither the consensus to accept or reject this work.
>
> Without rough consensus to adopt, the work is not adopted.
>
> But your statement above isn't accurate - it wasn't "this work"
> (as in this draft) that was discussed in Prague, but rather the
> entire idea of weakening TLS in these ways - quoting from the
> Prague minutes [1]:
>
> "The main question: Is this subject something that the WG should
> consider?"

The hummed answer to that question was very close to 50/50 in the
room, inconclusive.

>
> There is clearly no consensus to adopt *any* work in this space,
> whether that be draft-green or this latest iteration from Russ
> and Ralph.

It was clear that there was no consensus to adopt draft-green and that
is considered dead in the water, we agree there.  Since there was
interest (50% of the room) to consider work in this space, I agree
with the chairs assessment to allow this presentation.  I am confident
they will work on any hums to carefully assess next steps and if any
future proposals belong in this WG or elsewhere.

>
> I see nothing whatsoever to indicate any significant change in
> sets of opinions since Prague.
>
> What makes you think iterating on yet more proposals like this
> will ever conclude? If there's no evidence of that we ought not
> waste the time and energy. Can you point at any change that
> could possibly indicate that this bun-fight is worth doing yet
> again?
>
>>  The authors have
>> revised their proposal to address some of the concerns raised by working
>> group members and are asking to bring the new approach in front of the
>> working group.
>
> What significant change has there been since -00 of Russ and Ralph's
> draft? I see nothing major there. that -00 was debated on the list
> which is the primary place for  discussion. My read of that set of
> threads it that it pretty clearly showed that the same folks have
> the same opinions with no significant movement. Can you point at
> some evidence to the contrary? If not, we shouldn't bother to waste
> more time on this.
>
> If instead you mean Russ and Ralph's draft differs from draft-green,
> then see above - it wasn't only draft-green that was rejected in
> Prague, but the entire idea of adopting work in this space, which
> includes Russ and Ralph's -00 and -01.
>
> That the authors have asked for time counts for nothing, when the
> WG have no consensus to work in this space. If just asking for time
> does matter, then I'll now publicly repeat my request for time
> to refure the assertions that'll be made for breaking TLS. You said
> no to my request, so what's different about one that relates to a
> draft that has been debated on the list and attracted significant
> negative comment?
>
>> I believe in this case this is the right thing to do even
>> if it appears there is some repetition of topic.
>
> It is not "some repetition" - this topic has been debated f2f and
> on this draft on the list and there's zero evidence of significant
> changes in opinion, in fact the opposite. Can you point at any
> such evidence? If not, your position as chairs seems illogical.
>
>> However, if the new
>> approach fails to achieve significantly more support I believe the authors
>> will need to find another path for their work that does not go through the
>> TLS working group.
>
> But the WG has already demonstrated a lack of consensus to even
> consider "work in this space" (your choice of words I believe.)
> That should be enough. What does or doesn't happen outside the
> TLS WG is not at issue here.
>
> To reiterate, in Prague you asked "The main question: Is this subject
> something that the WG should consider?" The result was a clear lack of
> any consensus to work in this space, which means not working in this
> space. Yet here we are again giving agenda time to highly controversial
> proposals in this space.
>
> Please: just take this off the agenda and let the WG do it's real work.
>
> Thanks,
> S.
>
> [1] https://datatracker.ietf.org/meeting/99/materials/minutes-99-tls

Relevant comment from minutes:
Hums: No clarity whatsoever. Seemed pretty even.

Best,
Kathleen

>
>>
>> Cheers,
>>
>> Joe
>>
>> On Thu, Mar 8, 2018 at 9:21 AM, Stephen Farrell 
>> wrote:
>>
>>>
>>> Hi Sean, Joe,
>>>
>>> On 08/03/18 16:20, Sean Turner wrote:
 I’ve posted the draft agendas:

 Monday:
   https://datatracker.ietf.org/meeting/101/materials/agenda-
>>> 101-tls-sessb
>>>
>>> That includes:
>>> "
>>> TLS Vizability - Russ & Chairs - 30min
>>>  - 10min draft - Russ
>>>   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>>>  - 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Kathleen Moriarty]

Mirja,

On Wed, Mar 7, 2018 at 2:03 PM, Eric Rescorla  wrote:
>
>
> On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF)
>  wrote:
>>
>> > > Still, I find it
>> > > especially confusing that also two TLS1.2 extensions are deprecated
>> > > which are not needed with TLS1.3 anymore but still probably valid to
>> > > be used with TLS1.2, right?
>> >
>> > Which extensions are you referring to.
>>
>> RFC5077 and RFC6961 (maybe extension is not the wrong term for the first
>> one)
>
>
> OK. I'm not really sure of a better way to handle this.
>
>
>>
>> > > I would recommend for this version to at
>> > > least already note in the abstract or very early in the intro that it
>> > > changes the versioning mechanism itself, and thereby basically
>> > > declares the TLS handshake as an invariant for all future versions and
>> > > extensibility is only provided using extensions anymore.
>> >
>> > It's true that we are deprecating the version mechanism, but that
>> > does not mean that it is the only extension mechanism.
>>
>> Which others do you have?
>
>
> Once you have negotiated a new version you can change the messages in any
> way you please, just as you always could have.
>
>
>
>> > > 2) Can you provide further explanation (potentially in the draft) why
>> > > the Pre-Shared Key Exchange Modes are provided in an extra/separate
>> > > extension?
>> >
>> > I'm sorry, I'm not following this. As opposed to what?
>>
>> You could implicitly make assumptions depending on which extension are
>> present or you can add one field to the pre_shared_key extension to indicate
>> the mode. I’m always careful is something says „if this think is present,
>> that must also be present“ as it can be an source of error that could have
>> been avoided.
>
>
> Yes, we considered this design, and rejected it because we wanted a way to
> indicate which kinds of PSKs the client would be willing to accept.
>
>
>>
>> > > 3) I know previous versions of TLS didn't say that much either, but I
>> > > find it a bit wired that there are NO requirements for the underlaying
>> > > transport in this document. Previous version this at least said in the
>> > > intro that a reliable transport (like TCP) is assumed, but even this
>> > > minimal information seems to have gotten lost in this
>> > > document. However, I would usually also expect to seen some minimal
>> > > text about connection handling, e.g. is it okay to transparently try
>> > > to reestablish the connection by the underlying transport protocol if
>> > > it broke for some reason? Or it is okay to use the same TCP connection
>> > > to first send other data and then start the TLS handshake?
>> >
>> > This is pretty explicitly outside the scope of TLS. It's just the job
>> > of the underlying transport to simulate a reliable stream. I can add
>> > some text that that's expected.
>>
>> If that is the only requirement, it would still be good to spell that out.
>>
>
> Sure, I can add something.
>
>>
>> >
>> > > 4) Regarding the registration policies: I assume the intend of
>> > > changing them is to make it easier to specify and use new
>> > > extensions/mechanism. However, I am wondering why the policies have
>> > > been changed to "Specification Required" and not "IETF consensus" or
>> > > RFC Required"?
>> >
>> > The changes aren't in this document, but the WG feeling was that
>> > both of those were creating bad incentives for people to publish
>> > RFCs just to get a code point. The "Recommended" flag was intended
>> > to address that need instead.
>>
>> Hm, I think I would actually prefer to see things documented in RFCs
>> instead of just having some spec somewhere. Not sure if an RFC on the ISE
>> stream is that much more effort than writing a spec somewhere else but then
>> at least the IESG would get to see it for a conflict review..
>
>
> Well, I can see how you would feel that way, but it was the consensus of the
> WG that that was not the right approach.

I agree with Eric and poked at this in my AD review of the recent
policy changes.  There is strong WG consensus to allow for informal
documentation such as an unpublished draft.  As such, I support that
consensus as sponsoring AD since our procedures allow for this
flexibility and it makes sense.

Thanks for your review and comments, it's helpful.
Kathleen

>
>
>
>> > > 5) I find it a bit strange that basically the whole working group is
>> > > listed as contributors. My understanding was that Contributors are
>> > > people that have contributed a "significant" amount of text, while
>> > > everybody else who e.g. brought ideas in during mailing list
>> > > discussion would be acknowledged only.
>> >
>> > I don't think we have any IETF-wide standard here, but traditionally
>> > we have adopted a pretty generous attitude towards acknowledgements
>> > of this type. Given that electrons are basically free, I don't see a
>> > real
>> > problem here.
>>
>> I just would have expected to see all 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Kathleen Moriarty]

Thanks for your review, Mirja.  I will just add one comment inline
from WG discussion and consensus.

On Wed, Mar 7, 2018 at 1:05 PM, Eric Rescorla  wrote:
>> 1) I'm a bit uncertain if obsoleting is the right approach as many
>> other protocols usually do not obsolete older versions. However, I
>> understand that this has been the approach TLS has previously taken
>> and is supported by the way the document is written.
>
> Well:
> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
> says:
> A document is obsolete when there is a newer version that replaces it.
>
> I believe that that's the relationship between TLS 1.3 and TLS 1.2.
>
>
>> Still, I find it
>> especially confusing that also two TLS1.2 extensions are deprecated
>> which are not needed with TLS1.3 anymore but still probably valid to
>> be used with TLS1.2, right?
>
> Which extensions are you referring to.
>
>
>> I would recommend for this version to at
>> least already note in the abstract or very early in the intro that it
>> changes the versioning mechanism itself, and thereby basically
>> declares the TLS handshake as an invariant for all future versions and
>> extensibility is only provided using extensions anymore.
>
> It's true that we are deprecating the version mechanism, but that
> does not mean that it is the only extension mechanism.
>
>
>
>> 2) Can you provide further explanation (potentially in the draft) why
>> the Pre-Shared Key Exchange Modes are provided in an extra/separate
>> extension?
>
> I'm sorry, I'm not following this. As opposed to what?
>
>
>> 3) I know previous versions of TLS didn't say that much either, but I
>> find it a bit wired that there are NO requirements for the underlaying
>> transport in this document. Previous version this at least said in the
>> intro that a reliable transport (like TCP) is assumed, but even this
>> minimal information seems to have gotten lost in this
>> document. However, I would usually also expect to seen some minimal
>> text about connection handling, e.g. is it okay to transparently try
>> to reestablish the connection by the underlying transport protocol if
>> it broke for some reason? Or it is okay to use the same TCP connection
>> to first send other data and then start the TLS handshake?
>
> This is pretty explicitly outside the scope of TLS. It's just the job
> of the underlying transport to simulate a reliable stream. I can add
> some text that that's expected.
>
>
>> 4) Regarding the registration policies: I assume the intend of
>> changing them is to make it easier to specify and use new
>> extensions/mechanism. However, I am wondering why the policies have
>> been changed to "Specification Required" and not "IETF consensus" or
>> RFC Required"?
>
> The changes aren't in this document, but the WG feeling was that
> both of those were creating bad incentives for people to publish
> RFCs just to get a code point. The "Recommended" flag was intended
> to address that need instead.

The working group explicitly feels that a draft that is not published
is adequate, falling into the specification required category where
informal documentation is acceptable.


Thanks,
Kathleen

>
>
>> 5) I find it a bit strange that basically the whole working group is
>> listed as contributors. My understanding was that Contributors are
>> people that have contributed a "significant" amount of text, while
>> everybody else who e.g. brought ideas in during mailing list
>> discussion would be acknowledged only.
>
> I don't think we have any IETF-wide standard here, but traditionally
> we have adopted a pretty generous attitude towards acknowledgements
> of this type. Given that electrons are basically free, I don't see a real
> problem here.
>
> -Ekr
>
>
> On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind  wrote:
>>
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-tls-tls13-26: 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-tls13/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> 1) I'm a bit uncertain if obsoleting is the right approach as many other
>> protocols usually do not obsolete older versions. However, I understand
>> that
>> this has been the approach TLS has previously taken and is supported by
>> the way
>> the document is written. Still, I find it especially confusing that also
>> two
>> TLS1.2 extensions are deprecated which are not needed with TLS1.3 

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty]

On Thu, Feb 22, 2018 at 11:17 AM, Shumon Huque <shu...@gmail.com> wrote:
> On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>>
>> On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque <shu...@gmail.com> wrote:
>> > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <vik...@dukhovni.org>
>>
>> >
>> > Have other TLS extension specs gone into the details of middlebox
>> > impacts?
>>
>> This one is a little different though as end users are expecting e2e
>> without interference with this extension.  Understanding the behavior
>> is important for administrators and users as Viktor stated.
>>
>> Best regards,
>> Kathleen
>
>
> Okay Kathleen.
>
> We'll add some discussion on this. Viktor - I assume you'll help with text.

Thank you!

>
> Shumon.
>



-- 

Best regards,
Kathleen

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty]

On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque <shu...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <vik...@dukhovni.org>
> wrote:
>>
>>
>>
>> > On Feb 21, 2018, at 11:00 AM, Shumon Huque <shu...@gmail.com> wrote:
>> >
>> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
>> > <martin.thom...@gmail.com> wrote:
>> > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>> > <kathleen.moriarty.i...@gmail.com> wrote:
>> > > What's the behavior when the middlebox is a proxy, let's say existing
>> > > a managed network?  I presume from from section 3.1 that this
>> > > negotiation doesn't work in that instance unless sites configured for
>> > > this are not subject to the proxy as is often done for financial site
>> > > access from corporate networks.  It would be good to know if it does
>> > > work and that is addressed with the text Mirja calls out for her #1
>> > > question.  Having this clarified could be helpful.
>> >
>> > If there is a MitM, then this extension simply isn't negotiated.
>> > That's pretty well understood.  I don't see why that requires special
>> > mention.
>> >
>> > Yeah, I agree Martin .. this is the same as with any other extension.
>>
>> Actually, I don't think it is quite the same.
>
>
> I meant same in the sense that if any extension is blocked then it
> can't be used. What the effect of that is depends obviously on what
> functionality the extension is providing. The TLS client can at least detect
> such blocking/stripping, and alert the application or fallback to something
> else.
>
> Have other TLS extension specs gone into the details of middlebox
> impacts?

This one is a little different though as end users are expecting e2e
without interference with this extension.  Understanding the behavior
is important for administrators and users as Viktor stated.

Best regards,
Kathleen
>
>>
>>   This extension may
>> be naïvely expected to provide a different peer authentication
>> mechanism than the traditional WebPKI.  Users who might expect this
>> extension to protect them from WebPKI compromise via DANE TLSA
>> records, need to understand that such protection only exists when
>> DANE is enforced (mandatory) by the client.
>>
>> The absence of DANE TLSA records, which is downgrade-resistant
>> when the client has access to DNSSEC authenticated denial of
>> existence (makes its own DNSSEC lookups) is no longer downgrade-
>> resistant when delivered via this extension if the client
>> is willing to accept just WebPKI in the (apparent) absence of DANE
>> TLSA records.
>
>
> Some of this is already discussed or at least implicit in the draft.
> If you want to propose specific text to add or modify, please do so ..
>
> Shumon.
>



-- 

Best regards,
Kathleen

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty]

On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque <shu...@gmail.com> wrote:
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <martin.thom...@gmail.com>
> wrote:
>>
>> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>> <kathleen.moriarty.i...@gmail.com> wrote:
>> > What's the behavior when the middlebox is a proxy, let's say existing
>> > a managed network?  I presume from from section 3.1 that this
>> > negotiation doesn't work in that instance unless sites configured for
>> > this are not subject to the proxy as is often done for financial site
>> > access from corporate networks.  It would be good to know if it does
>> > work and that is addressed with the text Mirja calls out for her #1
>> > question.  Having this clarified could be helpful.
>>
>> If there is a MitM, then this extension simply isn't negotiated.
>> That's pretty well understood.  I don't see why that requires special
>> mention.
>
>
> Yeah, I agree Martin .. this is the same as with any other extension.

OK, I think it is clear in the discussion with 1.2, but wasn't sure if
it was clear enough elsewhere and figured it was best to ask.
>
> Shumon.
>



-- 

Best regards,
Kathleen

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

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

[Kathleen Moriarty]

eplays interacting with non-idempotent services and throttling
>> configurations. While it's true that browsers can be made to replay
>> requests already, there are many web and non-HTTP services that are
>> certainly not tolerant of replays. Secondly, I think that it is inevitable
>> that vendor security compromises will disclose troves of user requests,
>> passwords, credit cards to decryption; but this is perhaps more of a
>> nation-state-adversary level risk. Some more detail on attacks related to
>> issues 1/ and 2/ is available in the security review of 0-RTT data:
>> https://github.com/tlswg/tls13-spec/issues/1001 .
>> 
>> 
>> After all of that, here's my own position:
>> 
>> I strongly support the current TLS1.3 draft progressing to RFC status. I
>> work at Amazon, where one of our leadership principles is "Disagree and
>> Commit" (https://www.amazon.jobs/principles); the idea is that it's
>> important to make yourself heard, but also to move forward and not be
>> endlessly bogged down. I've been vocal about 0-RTT risks, and certainly
>> heard and understood, and those concerns have been reflected in generous
>> changes to the draft. I'm happy that it's possible to build a
>> forward-secret, non-repayable 0-RTT implementation and that's what I'm
>> doing. I wish everyone else would too, but that's not consensus; others
>> have a different weighting for the trade-offs between speed, security and
>> cost and those views are also legitimate.
>> 
>> But my more important reason for supporting is that overall TLS1.3 is much
>> much better than TLS1.2, including in regards to forward-secrecy, which is
>> now guaranteed for all non-0RTT data. I still believe that it will
>> meaningfully increase the overall security posture for the internet, and
>> I'm super excited to get it out and for users to be getting the benefits.
>> TLS has always been a bit of a mess, it's not as clean as something
>> designed by a single voice focused on modern cryptographic best-practices,
>> but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things
>> can't be improved further, and delay inflicts 1.2 and lower versions on
>> users for even longer. So let's go!
>> 
>> 
>> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>> 
>>> Dear Yuhong,
>>> 
>>> As the sponsoring Area Director, my job is to take the draft forward
>>> as was determined by working group consensus.  Like Stephen, I'm also
>>> not particularly happy about the choice to leave in 0-RTT, but I have
>>> to support it as a WG decision.  Whatever the version number in the
>>> ServerHello decision is from the WG, I will support that decision.
>>> The ServerHello decision doesn't really fall into the, "arms race" as
>>> you put it.  More on that in another thread.
>>> 
>>> Best regards,
>>> Kathleen
>>> 
>>> On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_...@hotmail.com>
>>> wrote:
>>>> I wonder what is IESG's opinion on the TLS arms race with middleboxes.
>>>> Yes, I am talking about moving the version number in the ServerHello.
>>>> 
>>>> 
>>>> From: TLS <tls-boun...@ietf.org> on behalf of The IESG <
>>> iesg-secret...@ietf.org>
>>>> Sent: Thursday, February 15, 2018 1:13:48 PM
>>>> To: IETF-Announce
>>>> Cc: draft-ietf-tls-tl...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
>>>> Subject: [TLS] Last Call:  (The Transport
>>> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
>>>> 
>>>> 
>>>> The IESG has received a request from the Transport Layer Security WG
>>> (tls) to
>>>> consider the following document: - 'The Transport Layer Security (TLS)
>>>> Protocol Version 1.3'
>>>>   as Proposed Standard
>>>> 
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final
>>>> comments on this action. Please send substantive comments to the
>>>> i...@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may
>>> be
>>>> sent to i...@ietf.org instead. In either case, please retain the
>>> beginning of
>>>> the Subject line to allow automated sorting.
>>>> 
>>>> Abstract
>>>> 
>>>> 
>>>>   This document specifies version 1.3 of the Transport Layer Security
>>

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

[Kathleen Moriarty]

On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
> Hi Colm,
>
> On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote:
>> Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd
>> like to boil down what I think are the nits and risks with 0-RTT, and if
>> others want to weigh in they can. I'll state my own position at the bottom.
>
> Thanks for this summary and review; I think it's well-said.

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

>
>> Broadly, I think there are three issues with 0-RTT:
>>
> [...]
>> At the same time though, most vendors have stated that they don't plan to
>> do that and instead have designed around limited replay time windows,
>> non-transactional strike registers, and non-forward secure tickets. This is
>> what I expect to see deployed, and already see with some TLS1.3 deployment
>> experiments.  TLS1.3 could be more restrictive here; limiting the size of
>
> I don't disagree.  It might be helpful to have a conslidated list of
> references for the vendor statements, so we can get a more clear
> picture of where to set our expectations.  Though of course I do not
> insist that you assemble one, and I do not want my comment to be
> seen as detracting from your review overall.

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

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

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

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

Best regards,
Kathleen
>
> -Benjamin
>
>>
>> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>> > Dear Yuhong,
>> >
>> > As the sponsoring Area Director, my job is to take the draft forward
>> > as was determined by working group consensus.  Like Stephen, I'm also
>> > not particularly happy about the choice to leave in 0-RTT, but I have
>> > to support it as a WG decision.  Whatever the version number in the
>> > ServerHello decision is from the WG, I will support that decision.
>> > The ServerHello decision doesn't really fall into the, "arms race" as
>> > you put it.  More on that in another thread.
>> >
>> > Best regards,
>> > Kathleen
>> >
>> > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_...@hotmail.com>
>> > wrote:
>> > > I wonder what is IESG's opinion on the TLS arms race with middleboxes.
>> > > Yes, I am talking about moving the version number in the ServerHello.
>> > >
>> > > 
>> > > From: TLS <tls-boun...@ietf.org> on behalf of The IESG <
>> > iesg-secret...@ietf.org>
>> > > Sent: Thursday, February 15, 2018 1:13:48 PM
>> > > To: IETF-Announce
>> > > Cc: draft-ietf-tls-tl...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
>> > > Subject: [TLS] Last Call:  (The Transport
>> > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
>

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

[Kathleen Moriarty]

Dear Yuhong,

My personal opinion in the "arms race" (your phrasing, not mine), no
AD hat on (as that one is to support the WG decision), is that it will
continue until we really hear each other out and think more on the
problems the other side is trying to solve.  Perhaps there are ways to
meet all or at least some of the goals in other ways.  If we don't
work together to understand the challenges, we'll never make progress
and remain in this arms race.  I also think that if you push on e2e in
protocol design without listening to the other side, protocols may not
enjoy the deployment percentages that you'd like to see, adoption
could be hindered.  Many of the operators have expressed that they
would like to see e2e and are fully supportive of privacy goals, but
are trying to figure out other ways to accomplish tasks.  Logging from
applications has been found to be lacking by many operators, if this
could be improved on the application side, then a shift to use end
point monitoring becomes more practical.  From the draft I have been
working on (toward the goal of increasing adoption of e2e protocols),
"The Effect of Pervasive Encryption on Operators", the following
logging types have been called out as being deficient:

Service providers typically use only headers at layers 2,3, and 4

   "packet tracing and inspection along the service path
   provides operators the visibility to continue to diagnose problems
   reported both internally and by their customers.  Logging of service
   path upon exit for routing overlay protocols will assist with policy
   management and troubleshooting capabilities for traffic flows on
   encrypted networks.  Protocol trace logging and protocol data unit
   (PDU) logging should also be considered to improve visibility to
   monitor and troubleshoot application level traffic."

Within the enterprise (where they already own all the data), logging
at a more granular level for application debugging will assist with a
transition to rely more on end points for diagnostics.   Interactions
between applications an databases has been called out as an issue that
could be improved with enhanced logs on transactions, queries, etc.
Fraud detection does rely on transaction monitoring already, but banks
are using network based tools as well for this and other incident
detection (data exfiltration, etc.).  In this case, pattern detection
is really helpful and that might include variances in sizes of
packets, destinations, times of transactions, types of data accessed
(by who, when), etc.  Some of this can still be done on the network
with encrypted traffic streams.

I personally think e2e would get further ahead in the arms race if
they spent time working to solve these other issues with operators so
that monitoring could move to the end point or closer to it.

Yoav has said it on list before, vendors of middleboxes often update
quickly.  My interpretation of that is continuing to alter the
protocol to break middleboxes won't work as a strategy to disrupt many
middleboxes.  Solving customer problems will have a much greater
impact toward improving deployment in my personal opinion.  Much of
this debate is about control anyway - application vs. network - and
not about privacy.  Many operators also support the goal of privacy
for end users.

Best regards,
Kathleen


On Mon, Feb 19, 2018 at 10:58 AM, Kathleen Moriarty
<kathleen.moriarty.i...@gmail.com> wrote:
> Dear Yuhong,
>
> As the sponsoring Area Director, my job is to take the draft forward
> as was determined by working group consensus.  Like Stephen, I'm also
> not particularly happy about the choice to leave in 0-RTT, but I have
> to support it as a WG decision.  Whatever the version number in the
> ServerHello decision is from the WG, I will support that decision.
> The ServerHello decision doesn't really fall into the, "arms race" as
> you put it.  More on that in another thread.
>
> Best regards,
> Kathleen
>
> On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_...@hotmail.com> wrote:
>> I wonder what is IESG's opinion on the TLS arms race with middleboxes.
>> Yes, I am talking about moving the version number in the ServerHello.
>>
>> 
>> From: TLS <tls-boun...@ietf.org> on behalf of The IESG 
>> <iesg-secret...@ietf.org>
>> Sent: Thursday, February 15, 2018 1:13:48 PM
>> To: IETF-Announce
>> Cc: draft-ietf-tls-tl...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
>> Subject: [TLS] Last Call:  (The Transport Layer 
>> Security (TLS) Protocol Version 1.3) to Proposed Standard
>>
>>
>> The IESG has received a request from the Transport Layer Security WG (tls) to
>> consider the following document: - 'The Transport Layer Security (TLS)
>> Protocol Version 1.3'
>>as Proposed Standard
&

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

[Kathleen Moriarty]

Dear Yuhong,

As the sponsoring Area Director, my job is to take the draft forward
as was determined by working group consensus.  Like Stephen, I'm also
not particularly happy about the choice to leave in 0-RTT, but I have
to support it as a WG decision.  Whatever the version number in the
ServerHello decision is from the WG, I will support that decision.
The ServerHello decision doesn't really fall into the, "arms race" as
you put it.  More on that in another thread.

Best regards,
Kathleen

On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao  wrote:
> I wonder what is IESG's opinion on the TLS arms race with middleboxes.
> Yes, I am talking about moving the version number in the ServerHello.
>
> 
> From: TLS  on behalf of The IESG 
> 
> Sent: Thursday, February 15, 2018 1:13:48 PM
> To: IETF-Announce
> Cc: draft-ietf-tls-tl...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
> Subject: [TLS] Last Call:  (The Transport Layer 
> Security (TLS) Protocol Version 1.3) to Proposed Standard
>
>
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document specifies version 1.3 of the Transport Layer Security
>(TLS) protocol.  TLS allows client/server applications to communicate
>over the Internet in a way that is designed to prevent eavesdropping,
>tampering, and message forgery.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/
>
> The following IPR Declarations may be related to this I-D:
>
>https://datatracker.ietf.org/ipr/2900/
>
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 
> (Informational - IETF stream)
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

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

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

[Kathleen Moriarty]

Hi Martin,

Thanks for your response.  I just wanted to check on this and not hold
up the draft in the process.  Thanks for also addressing Jim's
question.

Best regards,
Kathleen

On Sun, Feb 18, 2018 at 7:09 PM, Martin Thomson
<martin.thom...@gmail.com> wrote:
> I don't think that this targets a particular class of device, or that
> it is appropriate to label it as such.  Ideally, every implementation
> deploys this.  If the RFC cites 7228 and points at C1 (for example),
> that potentially gives the impression that it is *only* for those
> things.  That's not the intent.  The intent is to avoid further
> fragmentation of the ecosystem.
>
> That's just my prejudice though, I don't find these taxonomies to be
> especially helpful, other than in codifying design constraints.  For
> this, I'd prefer the design constraint to be simply "could it run
> TLS".
>
> On Sat, Feb 17, 2018 at 8:19 AM, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>> Hello,
>>
>> Thanks for your work on draft-ietf-tls-record-limit.  I just requested
>> IETF last call, so that should start soon.  The draft looks ready to
>> go, I'm just wondering if you could add in text into the introduction
>> to state the level of constrained device this is intended to help?
>>
>> If text is added, this can be addressed with an updated document after
>> all other IETF last call comments are addressed.  I placed the
>> document on the March 8th telechat.
>>
>> Thank you.
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

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

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

[Kathleen Moriarty]

Hello,

Thanks for your work on draft-ietf-tls-record-limit.  I just requested
IETF last call, so that should start soon.  The draft looks ready to
go, I'm just wondering if you could add in text into the introduction
to state the level of constrained device this is intended to help?

If text is added, this can be addressed with an updated document after
all other IETF last call comments are addressed.  I placed the
document on the March 8th telechat.

Thank you.



-- 

Best regards,
Kathleen

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

Re: [TLS] TLS 1.3

[Kathleen Moriarty]

On Thu, Feb 15, 2018 at 2:45 PM, Kathleen Moriarty
<kathleen.moriarty.i...@gmail.com> wrote:
> Hello,
>
> Thanks for all the hard work on TLS 1.3.  The chairs have handed off
> the document for IETF last call and I'll start that shortly.  There
> are some idnits that were just caught and are queued up for the next
> version - an unnecessary reference is removed.
>
> There are also a 6 RFCs obsoleted that are not referenced in the
> abstract and that should be addressed prior to IESG review.

I see Sean just added this to the shepherd report, so this should be fine.

  Please note that ID-nits complains about the obsoleted/
  updated RFCs not being listed in the abstract. This is
  intentional because the abstract is now a concise and
  comprehensive overview and is free form citations, as
  per RFC7322.

>
> The improved discussion on 0-RTT is much appreciated.
>
> --
>
> Best regards,
> Kathleen



-- 

Best regards,
Kathleen

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

[TLS] TLS 1.3

[Kathleen Moriarty]

Hello,

Thanks for all the hard work on TLS 1.3.  The chairs have handed off
the document for IETF last call and I'll start that shortly.  There
are some idnits that were just caught and are queued up for the next
version - an unnecessary reference is removed.

There are also a 6 RFCs obsoleted that are not referenced in the
abstract and that should be addressed prior to IESG review.

The improved discussion on 0-RTT is much appreciated.

-- 

Best regards,
Kathleen

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty]

On Thu, Feb 8, 2018 at 9:32 AM, Shumon Huque  wrote:
> On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop  wrote:
>>
>> Op 08-02-18 om 03:27 schreef Shumon Huque:
>> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > > > wrote:
>> >
>> > Mirja Kühlewind has entered the following ballot position for
>> > draft-ietf-tls-dnssec-chain-extension-06: No Objection
>> >
>> >
>> > --
>> > COMMENT:
>> >
>> > --
>> >
>> > Two minor, mostly editorial comments:
>> >
>> > 1) Intro (sec 2): " It also provides the
>> >ability to avoid potential problems with TLS clients being unable
>> > to
>> >look up DANE records because of an interfering or broken
>> > middlebox on
>> >the path between the client and a DNS server."
>> > Is that actually a well-known problem (can you provide a reference?)
>> >
>> >
>> > Some folks (at Google and NLnet Labs if I recall; maybe others) have
>> > done
>> > measurements to show this is an actual problem -- for a relatively small
>> > but
>> > still non-trivial fraction of clients. We'll try to see if we can dig up
>> > specific
>> > references to documents that could be cited.
>>
>> I wouldn't call it a relatively small fraction :)  DNSSEC is severely
>> hampered for end-entities by broken infrastructure in many different
>> ways.  Sometimes an upstream resolver can be used for positive DNSSEC
>> answers (i.e. existing records), but not for non-existent or wildcard
>> answers, because it simply doesn't forward the NSEC(3) proof for it.
>>
>>
>>
>> The last measurements we at NLnet Labs did was in July 2015:
>>
>> Gorjón, Xavier Torrent, and Willem Toorop.
>> "Discovery method for a DNSSEC validating stub resolver."
>> (2015)
>>
>> https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf
>>
>> Measurements were done with RIPE Atlas, with at the time +-8200 probes.
>> At the time only 56% of probes received enough DNSSEC data from their
>> upstreams to be able to perform DNSSEC validation for both positive and
>> non-existent answers (required for DANE).
>
>
> Ah, thanks. I'd forgotten that it was so high!
>
> I think my "relatively small" comment was recalling an earlier study (I
> think by
> Google) that saw a breakage of around ~ 5%, but I think that was just
> measuring
> the ability to lookup and obtain less common RR types and did not measure
> ability
> to perform full DNSSEC validation.

What's the behavior when the middlebox is a proxy, let's say existing
a managed network?  I presume from from section 3.1 that this
negotiation doesn't work in that instance unless sites configured for
this are not subject to the proxy as is often done for financial site
access from corporate networks.  It would be good to know if it does
work and that is addressed with the text Mirja calls out for her #1
question.  Having this clarified could be helpful.

Thanks.

>
> Shumon.
>



-- 

Best regards,
Kathleen

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

[TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt

[Kathleen Moriarty]

Thanks to the WG, chairs, and Stephen for your work on this draft and
Ben  for the additional review comments.  The following nit and
clarification points are in addition to Ben's suggested edits.  It
looks long, but should result in no or very minor easy changes with
text provided.

Section 9 -

Text nit:
   Despite the following behavior being crazy, experience has shown that
   some customers use the IANA registry as checklist against which to
   measure an implementation's completeness and some implementers
   blindly implement cipher suites.  Therefore, IANA [SHALL add/has
   added] the following warning to the registry:
Perhaps: s/crazy/unexpected and not advised/
Or s/crazy/unexpected and NOT RECOMMENDED/

Sections 8,10, 11, 13, and 15 all update the registration policy on an
existing registry.  The rules for registration vary slightly and I'd
like to confirm that this is what was intended:

Sections 8, 10, 11, 13
 Designated expert ensures the specification is publicly available.

Section 10, 13, 15
 Explicitly requires a standards track document.

Section 9 doesn't state either that the specification is publicly
available or a standards track document is required.

Next, I'd like to understand the WG's view on what "specification"
suffices for registries that do not require a standards track
document.  When you dig through 8126, we've had people on the IESG
debate what is meant and people on the IESG change over time as do
interpretations. Does this mean something as simple as an email to an
IETF list that can be referenced and won't be deleted, a draft that is
posted and never published, a standard in another standards body,
etc.?  If you only intend it to mean the last 2, I think you're okay
not elaborating further in the draft, but if an email is enough, I
think you may need some text.  I'd use the phrase from 8126, section
4.6, "informal documentation, e.g. public IETF mailing list".

Relevant text from 8126:

   "The intention behind "permanent and readily available" is that a
   document can reasonably be expected to be findable and retrievable
   long after IANA assignment of the requested value.  Publication of an
   RFC is an ideal means of achieving this requirement, but
   Specification Required is intended to also cover the case of a
   document published outside of the RFC path, including informal
   documentation."


Best regards,
Kathleen

On Wed, Jan 31, 2018 at 11:34 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On the "better late than never" front, I've got some nits:
>
> OLD:
>
>[...] A Standards Track document
>   [RFC8126] is REQUIRED to register an extension with the value
>   "Yes".
>
> NEW:
>
>   In order to register an extension with the value "Yes", a Standards
> Track
>   document [RFC8126] is REQUIRED.
>
> Since not all standards-track documents must register such extensions/cipher
> suites/etc.  (There are multiple occurrences of this text.)
>
>
> Is the "Exporter Value" table in the document supposed to have a
> "Recommended" column?
>
> Let's also double-check that the "WARNING: Cryptographic algorithms[...]"
> text does not always say "cipher suites listed here", even when talking
> about (e.g.) HashAlgorithm and SignatureAlgorithm.
>
> (Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".)
>
> Maybe capitalize "TBD" in "tbd but maybe tls-reg-rev...@ietf.org"?
>
>
> OLD:
>
>Recommended algorithms regarded as secure for general use at the time
>of registration, however, cryptographic algorithms and parameters
>will be broken or weakened over time.
>
> NEW:
>
>Recommended algorithms are regarded as secure for general use at the time
>of registration, however, cryptographic algorithms and parameters
>will be broken or weakened over time.
>
> NOTES:
>
> Add "are" to improve grammar.
>
>
> -Ben
>
>
> On 01/31/2018 08:35 AM, Sean Turner wrote:
>
> I have one PR that address both the WGLC comments (from mt and ekr):
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57
>
> If you’ve got other suggested changes let me know and I can submit another
> PR and do the final merges before you initiate the IETFLC.
>
> Cheers,
>
> spt
>
> On Jan 30, 2018, at 16:54, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>
> Great, thank you very much, Stephen!  I'll get it rolling towards
> publication with last call starting soon.  I'll do my review in the
> next couple of days.
>
> Best regards,
> Kathleen
>
> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell
> <stephen.farr...@cs.tcd.ie> wrote:

Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt

[Kathleen Moriarty]

Great, thank you very much, Stephen!  I'll get it rolling towards
publication with last call starting soon.  I'll do my review in the
next couple of days.

Best regards,
Kathleen

On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell
 wrote:
>
> Hi Kathleen,
>
> The WGLC for this has expired.
>
> There was only one explicit comment [1] saying to ship it.
> The WG have chatted about this a bunch of times though so
> FWIW I think it'd be fair to conclude there's pretty good
> consensus for this.
>
> Cheers,
> S.
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html
>
> On 15/01/18 21:34, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> Kathleen's a bit busy at the moment so asked that, as shepherd,
>> I kick off the WGLC for this one (as the two chairs are authors).
>> The idea is that I'll summarise the WGLC thread to her and she
>> can then decide if this is ready to move forward.
>>
>> So this starts a 2-week WGLC, ending on January 29th.
>>
>> Cheers,
>> Shepherdy Stephen.
>>
>> On 03/01/18 13:57, 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   : IANA Registry Updates for TLS and DTLS
>>> Authors : Joe Salowey
>>>   Sean Turner
>>>  Filename: draft-ietf-tls-iana-registry-updates-03.txt
>>>  Pages   : 16
>>>  Date: 2018-01-03
>>>
>>> Abstract:
>>>This document describes a number of changes to (D)TLS IANA registries
>>>that range from adding notes to the registry all the way to changing
>>>the registration policy.  These changes were mostly motivated by WG
>>>review of the (D)TLS-related registries undertaken as part of the
>>>TLS1.3 development process.  This document updates many (D)TLS RFCs
>>>(see updates header).
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03
>>>
>>>
>>> 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
>>
>
> --
> PGP key change time for me.
> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
> NewWithOld sigs in keyservers.
> Sorry if that mucks something up;-)



-- 

Best regards,
Kathleen

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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Kathleen Moriarty]

On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos
 wrote:
> On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck  wrote:
>>
>> On Thu, 14 Dec 2017 16:45:57 -0800
>> Colm MacCárthaigh  wrote:
>>
>> > But what would that look like? What would we do now, in advance, to
>> > make it easy to turn off AES? For example.
>>
>> I think this is the wrong way to look at it.
>>
>> >From what I'm aware nobody is really concerned about the security of
>> AES. I don't think that there's any need to prepare for turning off AES.
>>
>> The problem with PKCS #1 v1.5 is that it survived so long *after* its
>> was known that it was bad. I really recommend everyone who wants to
>> know how protocols go bad to read up on the Bleichenbacher
>> countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last
>> one. The chapter in 1.2 is a nightmare and I seriously fail to
>> understand how anyone could have seen that and think it's a good idea
>> to do that in order to stay compatible with a standard that was already
>> deprecated at that point.
>>
>> We know that when this group decided to deprecate both PKCS #1 1.5 and
>> RSA encryption that there were people trying to lobby against that. I'm
>> glad that this wasn't successful.
>
>
> RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact
> the security of TLS 1.3 is heavily tied to these primitives if servers
> support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice
> if we can only deprecate RSA PKCS#1 1.5 at some point.

Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS
1.2 and prior? I haven't noticed any discussion on that previously. Is
it just the code base and not those using it being unwilling to
upgrade supporting libraries?

>From RFC8017:

   To avoid implementation weaknesses related to the way errors are
   handled within the decoding operation (see [BLEICHENBACHER] and
   [MANGER]), the encoding and decoding operations for RSAES-OAEP and
   RSAES-PKCS1-v1_5 are embedded in the specifications of the respective
   encryption schemes rather than defined in separate specifications.
   Both encryption schemes are compatible with the corresponding schemes
   in PKCS #1 v2.1.

And, yes, I know deprecation is very hard, but if there's been no
effort, it should be considered as TLS 1.2 isn't going away anytime
soon.

Thanks,
Kathleen
>
> regards,
> Nikos
>
> [0]. https://github.com/tlswg/tls13-spec/pull/1123
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Kathleen Moriarty]

Sent from my iPhone

> On Oct 22, 2017, at 3:24 PM, Kathleen Moriarty 
> <kathleen.moriarty.i...@gmail.com> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Oct 22, 2017, at 2:40 PM, Ted Lemon <mel...@fugue.com> wrote:
>> 
>>> On Oct 22, 2017, at 1:54 PM, Russ Housley <hous...@vigilsec.com> wrote:
>>> No one is requiring TLS 1.3 that I know about.  However, there are places 
>>> that require visibility into TLS.  I will let one of the people that works 
>>> in a regulated industry offer pointers to the documents.
>> 
>> What they require is visibility into contents of the flow that they are 
>> using encryption to protect.   Right now, the protocol they are using is TLS 
>> 1.1 or TLS 1.2.   The right thing for them to do if they continue to need 
>> this visibility and are no longer permitted to use TLS 1.2 is to use 
>> IPsec+IKE, or some protocol that is designed for this use case, not to take 
>> a protocol designed specifically for securing flows from on-path 
>> eavesdropping and create a mode where it is easier to wiretap.
>> 
>> There is no reason other than momentum for them to switch to TLS 1.3 when it 
>> doesn't address their use case.
> 
> With no hat, I agree.
> https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward
> 

I should note that I have not read the new draft yet.  These threads keep me 
busy.
> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Kathleen Moriarty]

Sent from my iPhone

> On Oct 22, 2017, at 2:40 PM, Ted Lemon  wrote:
> 
>> On Oct 22, 2017, at 1:54 PM, Russ Housley  wrote:
>> No one is requiring TLS 1.3 that I know about.  However, there are places 
>> that require visibility into TLS.  I will let one of the people that works 
>> in a regulated industry offer pointers to the documents.
> 
> What they require is visibility into contents of the flow that they are using 
> encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
> TLS 1.2.   The right thing for them to do if they continue to need this 
> visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE, or 
> some protocol that is designed for this use case, not to take a protocol 
> designed specifically for securing flows from on-path eavesdropping and 
> create a mode where it is easier to wiretap.
> 
> There is no reason other than momentum for them to switch to TLS 1.3 when it 
> doesn't address their use case.

With no hat, I agree.
https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data-center-monitoring-searching-for-a-path-forward

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] notes for TLS WG Session 2 at IETF 99

[Kathleen Moriarty]

Hi,

The email seems to be missing some text that was in the etherpad (or
reordered maybe), so here it is again:

IETF99 TLS WG 2nd session (19-July-2017)

(all errors are JLH's)

Agenda/Administrivia

Exported Authenticators (EKR)

draft 21, hopefully close

WGLC #2 ended yesterday

Changes since -19

shorten HKDF labels

make post-handshake auth imp option

add per-ticket nonce, each ticket is assoc. w/ new PSK

new section 0-RTT anti-replay

Mandatory anti-replay (PR# 1059)

requires some bounded mechanism, but no specific technique

Should we adopt this? Any objections?

MT: every instance has to ensure that it only accepts the same 0-RTT
once... which means an unbounded state problem

EKR: imp in NSS would guarantee "as 0-RTT"

... "you must accept 0-RTT data once"

MT: We've got a window, only accept in that window, no guarantee either.

(No objections)

PR# 1053: Hashes that aren't hashes

HKDF-Expand-Label included a hash function that occasionally is not a hash.

essentially, SHA156(empty string) passed frequently to something else.

Probably worth saying "you can pass a null value, and not pass a hash"

EKR: any opinions?

MT: noticed while doing vectors draft, we do this once every
handshake. I don't care.

EKR: there are two places that it can happen.

MT: still, I could care less.

Hannes: doesn't make sense to change since people have implemented like this.

RLB: I agree with MT and Hannes. Like the current mechanism, can opt
with table of hash values.

Placeholder: NAT/Middleboxes

TLS 1.3 starting to show increased connection failure rates.

hard to meausre but 1-10%

Problem seems to be middleboxen

proposals are either make connection look more or less like TLS 1.2

Joe S: when will experiments complete?

EKR: depends on what we see. Will have data relatively soon, 4-8
weeks. Takes a while to get into a release... but nightlies and betas
give some indication of if it will work.

draft-ietf-tls-dnssec-chain-exstension (Melinda Shore)

completed WGLC on this draft.
(https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-dnssec-chain-validation-00.pdf)

excellent feedback so far.

(melinda summarizes changes)

record ordering (server canonicalization, yes or no?) No one came to mic.

use of _udp label for QUIC

Ted Hardie: reading of the draft is that UDP label used for DTLS and QUIC.

...: you might have two different TLSA records, one for DTLS and one
for QUIC. Maybe call it _quic?

Paul Woters: want to make sure we don't create a new plaintext reference

tell client imps how to handle unexpected/irrelevant/extraneous records?

Joe: we'll close on these remaining issues before reving the draft.

DTLS 1.3 (EKR)

first mentions something about exported authenticators:

certificate type extension goes in server [something] message.

odd thing is can have EE X.509 extension [somewhere] which is nuts.

Suggest we maintain the property where I change the entry in the table
and [something]

Trying to keep 1.2 functionality.

Reminder: ACKs

implicit ACKs historically.

interacts badly with some TLS 1.3 features (like NST)

Solution: intro an explicit ACK

current proposal: SACK

kind of ripping off the QUIC structure.

MT: other thing with it being a handshake message is that it adds to
the transcript record and that gets weird.

When should receivers ACK

supposed to ACK when you're not moving the state machine forward, when
messages might have gotten lost, not for non-handshake messages

If anyone thinks this is a bad strategy, please speak up.

Joe S: how many people have had a chance to look at this? Not too many.

Janardhan Igengar: would be nice if this is not too complicated.

Reduced Header Format

MT: we currently have range between 20-64 reserved for us in this
demux thing. We only use the lower half of the 20s... this uses the
upper half of that range from 32 onwards. Can use that entire space
and allows good distinguishing. Don't see us using too much more
content types.

EKR: essentially the point of doing something different would be to
have much longer sequence bits.

MT: not sure I've convinced Ian Swette [sp?]

SPT: thing about this is that the IoT will think we ned to make this
smaller... this seems about as small as you can get to.

MT: one optimization we could make in addition, would be to remove the length.

EKR: but that would make the ACK'ing problematic (?)

MT: other way to do that is to do some internal framing... "I've got
an ACK and some other stuff in here"

... real challenge here are the cases when you're changing keys. would
need internal lengths for those content types.

Connection IDs

have spent an enormous amount of time on this.

things behind NATs have problems rebinding.

also a serious privacy problem, none of the proposals I've seen are
adequate let alone completely baked.

huge problem in the browser context, not so much in the mobile context.

proposal for DTLS is to kind of punt: have an optional but fixed
Connection ID. Doesn't change across 

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kathleen Moriarty]

On Sun, Jul 16, 2017 at 5:14 AM, Salz, Rich  wrote:
> Within an enterprise that believes they need this kind of
> packet-capture-decode thing, what are the other benefits of TLS 1.3?  They
> can already use good ciphers. They save the cost of not uplifting existing
> infrastructure. They lose 0RTT early-data, which when viewed globally seems
> like a reasonable trade-off.

 My guess is that industries interested in the DH key proposal would
want 0-RTT.  I think they would want to prevent replay attacks and
might even see configuration errors of this as a risk (allowing 0-RTT
inadvertently).

>
>
> I am much more cynical about the value of opt-in.  I mean, what are you
> expecting users to agree to?  And globally, what infinitesimal portion of
> the Web population can make an informed choice?  And often there is no
> choice – one of the advocates here is from a statewide insurance company.
>
>
>
> So what is compelling about TLS 1.3 after you take away forward secrecy?  I
> really want to hear an answer to that question from folks who say they need
> TLS 1.3 but without it.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kathleen Moriarty]

On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins  wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
>> Whether it justifies a loss of security is a separate question.
>
>
> It isn't a loss of security - it's actually a net gain for security.
> Network visibility, independent of any end-host, is a key requirement for
> network security.

Visibility, yes, but I don't agree that you can't protect the network
if traffic is encrypted.  Many incident response teams are able to use
indicators of compromise (IoCs) for encrypted streams.

>
> As to the specific regulations, folks from the appropriate verticals will
> need to speak up.  I know vaguely that there are regulations in the
> financial sector and the defense contracting sector which apply, but can't
> cite chapter and verse.
>
> I'm sure someone on the list can, however.
>
>
> ---
> Roland Dobbins 
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kathleen Moriarty]

On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins  wrote:
> On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:
>
>> I'd like to hear from the people who are doing full-take network capture
>> within their datacenters about how they protect the security of the
>> internal decryption systems.
>
>
> Firstly, they generally aren't storing everything, forever.  Most of the
> time, they feed into collection/analysis systems, and most if not all of the
> actual packets are discarded.
>
> In many cases, they're only enabled on a situational basis - say, a security
> incident or a troubleshooting session.  Most if not all of the packets are
> discarded afterwards, in most cases.
>
> In most cases, they're running on completely out-of-band management
> networks, using transparent taps or SPAN ports or equivalent.  In some
> cases, they can be used to intervene in the cryptostream - but even in that
> in-band case, all the management functions are still isolated on out-of-band
> management networks which are not interconnected with the production
> network, and are further isolated as necessary by implementing
> situationally-appropriate network access policies.

When I have done this in the past in environments I've managed, I
always used a one way cable (receive only), set up the interface for
receive only, and then use the same protection mechanism offered by
the switch.


>
>> It certainly sounds like a tempting target for any adversary interested in
>> datacenter operations.
>
>
> I guarantee you that your bank, your hospital, your insurance provider, your
> credit card processor, your retailer, and/or your government welfare agency
> are doing this, and have been doing it for a long time.
>
> It's quite common in the national security space, as well as other
> governmental bureaux.
>
> I'm not saying everyone has implemented this perfectly, or optimally - but
> it is a common practice which has been going on for many years, and the loss
> of the ability to perform these functions would result in a net security
> loss for these organizations and for their customers and constituents -
> i.e., proles like you and me.
>
> It isn't new, it isn't unique, it isn't a case of a small group engaging in
> special pleading.  What's amazing is that very few engaged in this
> discussion seems to understand all this.
>
> ---
> Roland Dobbins 
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kathleen Moriarty]

Hi Roland,

It sounds like you misread my messages and should read them in context of TLS 
1.3 and the draft using DH static keys proposed to help with monitoring.

Best regards,
Kathleen 

Sent from my iPhone

> On Jul 14, 2017, at 8:41 PM, Roland Dobbins  wrote:
> 
>> On 15 Jul 2017, at 1:01, Melinda Shore wrote:
>> 
>> It might make sense to kick it over to ops for a discussion with people 
>> whose meat and potatoes is monitoring, management, and
>> measurement.
> 
> As someone who is ops-focused, I think this is an excellent suggestion!
> 
> There have been several assertions posted to the list recently regarding 
> various aspects of security and their intersection with encryption.  It may 
> be useful to take a moment and clarify a few of them.
> 
> With regards to DDoS mitigation as it relates to encrypted attack traffic, 
> only a subset of attacks in a subset of situations can actually be adequately 
> mitigated without full visibility into (and often the ability to interact 
> with) the traffic within the cryptostream.  There are various ways to 
> approach this issue, including full session termination and 'transparent' 
> detection/classification, the latter of which isn't of course feasible in a 
> PFS scenario.  Each of these general approaches has its advantages and 
> drawbacks.
> 
> Very specifically, fingerprints of encrypted streams are not in fact adequate 
> for DDoS defense; again, they're only useful for a subset of attack types in 
> a subset of situations.
> 
> In the case of detecting and classifying hostile activity within a given 
> network - which isn't limited to malware spreading, but includes data 
> extraction, attempts at unauthorized access, attempts at subverting 
> additional devices, et. al. - the same basic caveats apply.  It is not in 
> fact possible to adequately detect and classify all, or even a large subset, 
> of hostile network traffic without visibility into the cryptostream.  There 
> are some gross behaviors which can be detected/classified whilst standing 
> outside the tunnel, but assertions to the effect that all or most of what's 
> required in this arena is possible without visibility (one way or another) 
> into the relevant encrypted traffic are incorrect.
> 
> It's also important to understand that inserting proxies into multiple points 
> of a network topology is not cost-free, nor an unalloyed good.  It is 
> impractical in many circumstances, and has highly unwelcome side-effects in 
> many more, including a negative impact on reliability, performance, and 
> availability, as well as broadening the potential attack surface.  Endpoint 
> monitoring does not scale well, is often impossible to implement due to both 
> technical and administrative challenges - and one can't really trust 
> endpoints to self-report, anyways, as they can be subverted.
> 
> In many scenarios, one form or another of network-based visibility into 
> encrypted traffic streams within the span of administrative control of a 
> single organization is legitimate, vital and necessary.  It is not 
> 'wiretapping', any more than tools such as tcpdump or telemetry formats such 
> as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is, the 
> availability, confidentiality, and integrity of systems, applications, and 
> networks that everyone on this list relies upon is highly dependent upon the 
> ability of organizations to have visibility into encrypted traffic streams 
> within their own networks, for purposes of security as well as testing and 
> troubleshooting.
> 
> How this can be accomplished is a matter for further discussion.  But it's 
> important that everyone focused on this topic understands that it is simply 
> not possible to successfully defend against many forms of DDoS attacks nor to 
> detect and classify hostile network traffic in the context of encrypted 
> communications without visibility into the traffic in question, via some 
> mechanism.  The same goes for troubleshooting complex problems.
> 
> Those with operational experience at scale will likely recognize and 
> acknowledge the difficulties and challenges noted above; others may wish to 
> consider these factors and their impact on the operational community and the 
> networks, services, and applications for which they are responsible, and upon 
> which we all depend, every day.
> 
> ---
> Roland Dobbins 
> 
> ___
> 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] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

[Kathleen Moriarty]

Sent from my iPhone

> On Jul 14, 2017, at 8:02 AM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 
> On 14 July 2017 at 01:08, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>> It sounds like for malware, we could do something to better document
>> your security options as well as monitoring.  While the documentation
>> is there for key pinning and trust anchors, this might not be obvious
>> to network managers - what RFC to look at and how they fit together.
> 
> Just an aside, though I think Kathleen already made this point:  If I
> were writing malware, I would use TLS.  It's pretty good at what it
> does and it's hard to distinguish from legitimate uses (there are some
> trick's suggested by McGrew's research on this point).
> 
> At the point that I have sufficient control over a host that I can run
> my software, then I would pin certificates and the best you could do
> is block me.  None of the advice about configuration of trust anchors
> (pinning, overrides, etc...) helps at that point.

I do think we could help tie together this advice for the many operators using 
TLS so they know and understand options better.

Yes, agreed, detection at that point relies on anomalous behavior on the 
managed end point, connection information (unusual destination, size of 
packets, timing of streams, etc.), or known indicators of compromise.  These 
all work with encryption and TLS should not be a hinderance to incident 
detection at that point
> 
> Most discussions regarding breaking TLS focus on the breaking of TLS
> to *prevent* malware from infesting machines.  There at least the
> defender has a reason to attack end-to-end security.  But then we're
> talking about a very different deployment model than the gazillion
> emails recently have contemplated.

I think the points on why the solution doesn't help with malware have been 
clear, but just in case, preventing malware from infecting endpoints receiving 
content over HTTP/TLS can also be done using indicators of compromise.  
Breaking TLS only works if the malware has been identified and can be detected 
by the analysis box. This does work when it's been deployed to newly infected 
servers when the malware hasn't been altered enough to avoid detection.  This 
is useful to enterprises, but you'd need the server key or more realistically 
going forward, would need a TLS proxy. Otherwise, with the proposed solution, 
your still relying on indicators of compromise that can be detected using the 
encrypted traffic.

Best regards,
Kathleen 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kathleen Moriarty]

Hi Steve,

Thanks for taking the time to detail out your concerns and current use
cases.  This is helpful.

On Tue, Jul 11, 2017 at 9:39 PM, Martin Thomson
 wrote:
> On 12 July 2017 at 09:59, Steve Fenter  wrote:
>>> And if you had one an estimate for how much malware does it's own
>>> obfuscation or home-grown crypto in addition or instead of using TLS.
>>> The reason to ask is that as soon as malware does that then you
>>> are back to analysis based on ciphertext only. From descriptions
>>> of advanced attack schemes, they do seem to do both when calling
>>> home or exfiltrating data. In which case I think your argument
>>> falls.
>>
>> I don't have any numbers for home-grown crypto.  I would think the odds are 
>> better for the enterprise if they can decrypt and inspect whatever portion 
>> is TLS.
>
> Wouldn't malware avoid connecting to servers that offer the wrong
> credentials?  Implementing elementary key pinning or overriding trust
> anchors is pretty trivial - it's a feature that enterprises frequently
> rely on after all.

It sounds like for malware, we could do something to better document
your security options as well as monitoring.  While the documentation
is there for key pinning and trust anchors, this might not be obvious
to network managers - what RFC to look at and how they fit together.

The points Stephen, Ted, Martin have made are good.  A TLS overview
document with an appendix of use cases might be a good start to help
fill this gap for operators.  Even if it isn't published, we could
figure out wiki space or something like wikipedia to make sure it's
available to operators. If the start of this documentation looks like
it will generate new work developing alternate ways to accomplish the
goals while maintaining the integrity of TLS, a new WG could even be
an option.

For malware, the proposed solution (Matt Green draft) isn't a great
fit as the server side won't be managed within your enterprise to
allow for the decryption described in the proposal.

For the other parts of your original message that were snipped from
this thread, I have a few questions/comments to see how we might be
able to narrow the scope and clarify a few things.

For the Troubleshooting description, could redefining the end point of
the server work as terminating at a load balancer to help with at
least some of your use cases?

For the threat detection and security analytics, I know a number of
current products rely on the ability to TLS.  The primary concern here
would be the remote server not managed by the enterprise.  TLS 1.3
prevents this from being possible and the proposed draft doesn't help,
so I think it would be best to figure out a way forward for this use
case either with the help of MILE (incident responders) or others.
Currently products use proprietary methods to accomplish this task (at
least some do).  For DDoS, the experts say they can work with
fingerprints of encrypted streams, so it's other attack types that may
require some thinking through of options.  I'm happy to chat about
that as I've done a lot of work in incident response and know of
others that may be able to assist as well.

I'm still reading through messages and drafts on this topic, so this
message should not be read as a position on either side, but more to
narrow the scope if possible and think through what is being requested
and why - so it is clarified.

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



-- 

Best regards,
Kathleen

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

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Kathleen Moriarty]

With no hat on...

Sent from my iPhone

> On Jul 12, 2017, at 6:18 PM, Stephen Farrell  
> wrote:
> 
> 
> 
>> On 12/07/17 16:54, Kyle Rose wrote:
>> On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell >> wrote:
>> 
>>> 
>>> 
 On 12/07/17 16:27, Kyle Rose wrote:
 The telco in the POTS case isn't either endpoint. The third-party
 surveillance is unknown to those endpoints. Therefore: wiretapping.
>>> 
>>> Same in the wordpress.com or smtp/tls cases already
>>> described on list. Therefore: wiretapping.
>>> 
>>> My point was that "collaborating" does not mean not
>>> wiretapping. Saying otherwise is what'd be silly.
>>> 
>> 
>> And yet that's what 2804, what you have repeatedly cited, explicitly
>> states. I'm going to go with the definition given there, "silly" or not.
> 
> The definition in 2804 is not silly, nor did I say it was.
> 
> I said your implication that "collaboration" => "not
> wiretapping" was silly.
> 
>> This isn't wiretapping: it's *something else* potentially bad, but not all
>> surveillance is wiretapping.
> 
> Not all surveillance is wiretapping, sure, that is
> true.
> 
The difference with the WordPress & SMTP examples is that you know content will 
sit in plaintext on the servers, whereas with POTS, you need to wiretap to get 
the voice content. You only expect the log that the call transpired to exist 
with the service provider.

I'm still in a mode of listening to arguments,  but wanted to point this out in 
case better examples emerged.

Thanks,
Kathleen 


> What is also true is that the draft being discussed
> is entirely clearly usable for wiretapping in some
> applications that use TLS according to the definition
> in 2804.
> 
> S.
> 
> 
>> 
>> Kyle
>> 
> 
> ___
> 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] AD Review of draft-ietf-tls-tls13

[Kathleen Moriarty]

On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni
<ietf-d...@dukhovni.org> wrote:
>
>> On May 16, 2017, at 11:36 AM, Kathleen Moriarty 
>> <kathleen.moriarty.i...@gmail.com> wrote:
>>
>> OK, does that put us back to the suggested wording:
>>
>>"TLS depends on certificate path validation, and a conformant
>> TLS implementation MUST implement certificate paths validation
>> in a manner that achieves the same result as [RFC5280]. This
>> section provides TLS-specific requirements.”
>>
>> For any developers following, does this help enough with any
>> interoperability questions?
>
> TLS does not depend on certificate path validation.  Many TLS
> *applications* rely PKIX certificate path validation (along with
> RFC 6125 server identity verification), but TLS itself supports
> various alternative authentication (and non-authentication) modes.
>
>* PSK or SRP without certificates
>* Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <= 1.2)
>* TOFU public key pinning
>* Static leaf key or leaf cert matching
>* RFC7250 raw public keys
>* DANE-EE(3) leaf certificate/key verification, without expiration
>  or server name checks
>* DANE-EE(3) ... with name checks (where UKS attack are relevant)
>* DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
>  is part of the chain, and identified via DNS TLSA records.
>* PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
>* PKIX-TA(0) which is RFC5280 + DANE CA "constraint"
>
> Keeping in mind that many implementations of RFC5280 violate that 
> specification
> by interpreting EKUs in CA certificates to constrain the kinds of certificates
> that the CA may issue.  That de-facto usage is I think much more widely 
> implemented
> than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

Sorry, I grabbed the wrong text as I was ineffective at multi-tasking.
I think we are back to the following text and would like to confirm
that and make sure it is agreeable to the WG and implementers:

"In general detailed certificate validation procedures are out of
scope for TLS. [RFC5280] provides general procedures for
certificate validation. This section provides TLS-specific
requirements."

There's also a thread that was discussing some interoperability
problems related to validation and I'd like to see the resolution for
that as well.

Thanks,
Kathleen

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



-- 

Best regards,
Kathleen

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

[Kathleen Moriarty]

On Tue, May 16, 2017 at 11:31 AM, Russ Housley  wrote:
>
> On May 16, 2017, at 11:23 AM, Eric Rescorla  wrote:
>
>
>
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley  wrote:
>>
>>
>> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley 
>> wrote:
>>>
>>> Just commenting on Section 4.2 …
>>>
>>> >
>>> > > 3. Section 4.2.
>>> > >
>>> > >"In general, detailed certificate validation procedures are out of
>>> > >scope for TLS (see [RFC5280]).  This section provides TLS-specific
>>> > >requirements."
>>> > >
>>> > > I don't see an explanation of why it is out-of-scope.  The reference
>>> > > is just to RFC5280, which seems odd.  I would expect the reference to
>>> > > be to something that explains why it is out-of-scope.
>>>
>>> I think the the separation of certificate path validation from the TLS
>>> protocol is correct, but perhaps this can be explained differently.  Perhaps
>>> the approach should be that TLS depends upon certificate path validation as
>>> described in RFC 5280.
>>>
>>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>>> > job of TLS is to carry the certificates and other authentication
>>> > material but to leave it up to other parts of the system to
>>> > interpret them. It's been a long time since that decision was made,
>>> > but from my perspective, there are a number of major reasons:
>>> >
>>> > 1. Most of PKI processing (path construction, etc.) is generic and
>>> >not specific to TLS. What is specific to TLS is:
>>> >
>>> >* How to indicate what your PKI capabilities are
>>> >  (see, e.g, S 4.2.4 and 4.3.2)
>>> >* How to stuff the PKI material into the protocol
>>> >  (principally S 4.4.2)
>>> >* How to determine whether a given certificate is suitable for
>>> >  use in TLS 4.4.4.2 and 4.3.2.1).
>>> >
>>> >So we want to outsource the generic PKI part
>>> >
>>> >
>>> > 2. It matches the software architecture that people often use,
>>> >which is to have a TLS stack but separate PKI validation. For
>>> >instance, Firefox uses NSS for TLS but moz::pkix for
>>> >validation. Similarly, Chrome uses BoringSSL for TLS
>>> >but the system PKI libraries for validation.
>>> >
>>> >
>>> > In this case, I think that this text was more intended to
>>> > say "and go read 5280 to learn how to do this". To that end,
>>> > I suggest we say"
>>> >
>>> >
>>> > "In general detailed certificate validation procedures are out of
>>> > scope for TLS. [RFC5280] provides general procedures for
>>> > certificate validation. This section provides TLS-specific
>>> > requirements.”
>>>
>>> I agree with the reasoning, however the dependency on RFC 5280 should be
>>> called out in a MUST statement.  I suggest something like:
>>>
>>> "TLS depends on certificate path validation, and a conformant
>>> TLS implementation MUST implement certificate paths validation
>>> in a manner that achieves the same result as [RFC5280]. This
>>> section provides TLS-specific requirements.”
>>>
>>> Note that RFC 5280 is already a normative reference.
>>
>>
>> A MUST here would be a pretty material change to historical TLS practice.
>> As Viktor says, there are TLS-using applications that just don't validate
>> the cert via 5280 at all.
>>
>>
>> I think we want to say that if the certificates are used, then the
>> certification path MUST be validated in a manner that is compatible with
>> Internet X.509 certificate profile [RFC5280]; however, other approaches to
>> validation of the public key, such as the DANE TLSA resource record
>> [RFC6698], are also acceptable.
>
>
> I can see how you would want to say that, but it's not really consistent
> either
> with historical practice or with the way that other standards track RFCs use
> TLS
> with certificates (see RFC 5763).
>
>
> Actually, that is a great example.  I accept the need for loose coupling.

OK, does that put us back to the suggested wording:

"TLS depends on certificate path validation, and a conformant
 TLS implementation MUST implement certificate paths validation
 in a manner that achieves the same result as [RFC5280]. This
 section provides TLS-specific requirements.”

For any developers following, does this help enough with any
interoperability questions?

Thanks,
Kathleen

>
> Russ
>



-- 

Best regards,
Kathleen

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

[Kathleen Moriarty]

On Tue, May 16, 2017 at 11:17 AM, Russ Housley  wrote:
>
> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>
>
>
> On Mon, May 15, 2017 at 12:38 PM, Russ Housley  wrote:
>>
>> Just commenting on Section 4.2 …
>>
>> >
>> > > 3. Section 4.2.
>> > >
>> > >"In general, detailed certificate validation procedures are out of
>> > >scope for TLS (see [RFC5280]).  This section provides TLS-specific
>> > >requirements."
>> > >
>> > > I don't see an explanation of why it is out-of-scope.  The reference
>> > > is just to RFC5280, which seems odd.  I would expect the reference to
>> > > be to something that explains why it is out-of-scope.
>>
>> I think the the separation of certificate path validation from the TLS
>> protocol is correct, but perhaps this can be explained differently.  Perhaps
>> the approach should be that TLS depends upon certificate path validation as
>> described in RFC 5280.
>>
>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>> > job of TLS is to carry the certificates and other authentication
>> > material but to leave it up to other parts of the system to
>> > interpret them. It's been a long time since that decision was made,
>> > but from my perspective, there are a number of major reasons:
>> >
>> > 1. Most of PKI processing (path construction, etc.) is generic and
>> >not specific to TLS. What is specific to TLS is:
>> >
>> >* How to indicate what your PKI capabilities are
>> >  (see, e.g, S 4.2.4 and 4.3.2)
>> >* How to stuff the PKI material into the protocol
>> >  (principally S 4.4.2)
>> >* How to determine whether a given certificate is suitable for
>> >  use in TLS 4.4.4.2 and 4.3.2.1).
>> >
>> >So we want to outsource the generic PKI part
>> >
>> >
>> > 2. It matches the software architecture that people often use,
>> >which is to have a TLS stack but separate PKI validation. For
>> >instance, Firefox uses NSS for TLS but moz::pkix for
>> >validation. Similarly, Chrome uses BoringSSL for TLS
>> >but the system PKI libraries for validation.
>> >
>> >
>> > In this case, I think that this text was more intended to
>> > say "and go read 5280 to learn how to do this". To that end,
>> > I suggest we say"
>> >
>> >
>> > "In general detailed certificate validation procedures are out of
>> > scope for TLS. [RFC5280] provides general procedures for
>> > certificate validation. This section provides TLS-specific
>> > requirements.”
>>
>> I agree with the reasoning, however the dependency on RFC 5280 should be
>> called out in a MUST statement.  I suggest something like:
>>
>> "TLS depends on certificate path validation, and a conformant
>> TLS implementation MUST implement certificate paths validation
>> in a manner that achieves the same result as [RFC5280]. This
>> section provides TLS-specific requirements.”
>>
>> Note that RFC 5280 is already a normative reference.
>
>
> A MUST here would be a pretty material change to historical TLS practice.
> As Viktor says, there are TLS-using applications that just don't validate
> the cert via 5280 at all.
>
>
> I think we want to say that if the certificates are used, then the
> certification path MUST be validated in a manner that is compatible with
> Internet X.509 certificate profile [RFC5280]; however, other approaches to
> validation of the public key, such as the DANE TLSA resource record
> [RFC6698], are also acceptable.

I do like this a lot better as it will help with interoperability and
security, with well defined implementation guidance.

Thank you,
Kathleen

>
> Russ
>
>



-- 

Best regards,
Kathleen

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

[Kathleen Moriarty]

nd,
> I suggest we say"
>
>
> "In general detailed certificate validation procedures are out of
> scope for TLS. [RFC5280] provides general procedures for
> certificate validation. This section provides TLS-specific
> requirements."
>

This reads much better, thank you.  However, shouldn't it say TLS1.3
since TLS 1.2 referenced RFC3280 and subsequently in RFC7525 includes
use of RFC5280 as a best practice.  It may be true for TLS 1.0 and
1.1, but it changed for TLS 1.2/

>
>> RFC7525 has use of RFC5280 as a best practice for server identity
>> verification and revocation checks for TLS 1.2.  Is this just for TLS
>> 1.3?  Why?
>
> I think that these requirements apply equally to TLS 1.3, it's
> just that 7525 is older.

I think this was poor phrasing on my part for the point.  and is
hopefully clarified in my response above.  RFC7525 came after TLS 1.2
and updated it's guidance recommending 5280.

>
>
>> RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
>> explanation here would be helpful since this seems to be a departure
>> (or reference to the changes section).
>
> This is part of our generalized attempt to update to point to
> the latest RFCs in our references. I'll add something to the
> references section.
> https://github.com/tlswg/tls13-spec/issues/1015
>
>
>> If RFC5280 remains out-of-scope, this section should fully describe
>> the certificate validation process for TLS 1.3. I think you need to
>> list out everything that should be checked as opposed to just
>> including one example:
>>
>>"Also, if some aspect of the certificate chain was
>>unacceptable (e.g., it was not signed by a known, trusted CA), the
>>server MAY at its discretion either continue the handshake
>>(considering the client unauthenticated) or abort the handshake."
>
> In general, I think we'd prefer to avoid providing a catalog of
> all the ways that things can go wrong, because there are a lot.
> The point of the text here is just supposed to be that servers
> don't have to fail if they ask for client auth but they are then
> sad about what the client provides. That's actually generally kind
> of true, but it's more obvious with client auth because in many
> cases the server has many ways of authenticating the client and
> can fall back if it doesn't like the cert.

>From list discussions, the underspecification seems to be causing some
interoperability problems.  Maybe a response to the list discussion
with this point will result in something to improve this section and
clarity for developers.  I'll look in the next update.  Thank you.

>
>
>> 4. Section 6.2 Error Alerts
>>
>> In addition to sending the error, I don't see any mention of the error
>> being logged on the server side, shouldn't that be specified?  Logging
>> errors (at least in debug modes when needed) provides valuable
>> troubleshooting information and many applications don't do an adequate
>> job of logging, so I think it's important to call that out here as a
>> recommendation.
>
> I agree. I think it would be useful to say something about this. I've
> filed https://github.com/tlswg/tls13-spec/issues/1014 to track this.

Thank you, this is very helpful.

Best regards,
Kathleen

>
> -Ekr
>
>
> On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>>
>> Hello,
>>
>> Thank you all for your work on TLS 1.3.  The list has still been
>> active on a few topics, so I want to see how that all settles out in
>> addition to the questions I have on the draft below.
>>
>> Introduction:
>>
>> 1. Since this is going for IETF last call soon and there has been
>> review of the draft (workshop, but is clearly ongoing from the list
>> discussions), should the first sentence of the Introductions be
>> removed?
>>
>>DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
>>significant security analysis.
>>
>> 2. Section 4.2.9 - There should be some mention or pointer to the
>> security considerations and recommendations on replay attacks for
>> 0-RTT from this section.  I don't see any mention of discouraging
>> 0-RTT from being a default and think that would be good for
>> applications that use TLS expecting replay protection.  I know the WG
>> agreed to keeping 0-RTT, but I think it's very important to make the
>> issues clear and not have this come up as a default in any
>> implementation/deployment for unsuspecting users.  Part of this will
>> get down to implementation specifics and configuration options, but
>> offering s

[TLS] AD Review of draft-ietf-tls-tls13

[Kathleen Moriarty]

Hello,

Thank you all for your work on TLS 1.3.  The list has still been
active on a few topics, so I want to see how that all settles out in
addition to the questions I have on the draft below.

Introduction:

1. Since this is going for IETF last call soon and there has been
review of the draft (workshop, but is clearly ongoing from the list
discussions), should the first sentence of the Introductions be
removed?

   DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
   significant security analysis.

2. Section 4.2.9 - There should be some mention or pointer to the
security considerations and recommendations on replay attacks for
0-RTT from this section.  I don't see any mention of discouraging
0-RTT from being a default and think that would be good for
applications that use TLS expecting replay protection.  I know the WG
agreed to keeping 0-RTT, but I think it's very important to make the
issues clear and not have this come up as a default in any
implementation/deployment for unsuspecting users.  Part of this will
get down to implementation specifics and configuration options, but
offering some guidance is important. This document will be read by
many, not just developers.

Since clients have to initiate 0-RTT, the user has to have some idea
that replay attacks are possible and accept that risk.  If this were
used in web applications, then all servers that don't want to see
replay attacks (banking, etc.), would have to have explicitly reject
this usage.  As such, there needs to be very strong guidance to this
point. Would it be that browsers configure this as a default or
something users would have to turn on or just leave it as an option
(with warnings) for a client to enable?  Would servers have clear
information in configuration files (or setup) about the implications
of this option for those that don't read the RFC and are not aware of
this problem?

Most of this discussion belongs directly in the security consideration
section, but there has to be mention of it with a reference from
section 4.2.9.  It's not just an API consideration, this is for
developers, implementers, and users of the protocol. Many other
protocols use TLS beside HTTP and do so with the expectation of replay
protection.

While Appendix C1 is helpful, I don't think it's enough.  It's
disappointing to see a protocol with a replay attack written as a
prominent feature of TLS 1.3 and little discouragement from use.


3. Section 4.2.

   "In general, detailed certificate validation procedures are out of
   scope for TLS (see [RFC5280]).  This section provides TLS-specific
   requirements."

I don't see an explanation of why it is out-of-scope.  The reference
is just to RFC5280, which seems odd.  I would expect the reference to
be to something that explains why it is out-of-scope.

RFC7525 has use of RFC5280 as a best practice for server identity
verification and revocation checks for TLS 1.2.  Is this just for TLS
1.3?  Why?
RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
explanation here would be helpful since this seems to be a departure
(or reference to the changes section).

If RFC5280 remains out-of-scope, this section should fully describe
the certificate validation process for TLS 1.3. I think you need to
list out everything that should be checked as opposed to just
including one example:

   "Also, if some aspect of the certificate chain was
   unacceptable (e.g., it was not signed by a known, trusted CA), the
   server MAY at its discretion either continue the handshake
   (considering the client unauthenticated) or abort the handshake."


4. Section 6.2 Error Alerts

In addition to sending the error, I don't see any mention of the error
being logged on the server side, shouldn't that be specified?  Logging
errors (at least in debug modes when needed) provides valuable
troubleshooting information and many applications don't do an adequate
job of logging, so I think it's important to call that out here as a
recommendation.



-- 

Best regards,
Kathleen

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

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Kathleen Moriarty]

Yoav,

On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
>
> On 4 May 2017, at 16:09, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>
> I haven't approved it yet as I noticed there was no response (that I saw) to
> Alexey's comment and no change in the draft as a result of his comments.
>
>
>
> You mean these comments?
> https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0
>
> I’ll quote them here:
>
> 0) There is some general awkwardness in text talking about allowed points
> formats, considering that only uncompressed form is now allowed. I don't
> have recommendations about improving text, other than the following:
>
> If no future formats are expected, it feels almost better to recommend
> against inclusion of the Point formats extension, as lack of it means
> uncompressed format anyway.
>
> So this was addressed in draft -16:
>
> OLD:
>
>   Implementations of this document MUST support the
>uncompressed format for all of their supported curves, and MUST NOT
>support other formats for curves defined in this specification.  For
>backwards compatibility purposes, the point format list extension
>MUST still be included, and contain exactly one value: the
>uncompressed point format (0).
>
>
> NEW:
>
>   Implementations of this document MUST support the
>uncompressed format for all of their supported curves, and MUST NOT
>support other formats for curves defined in this specification.  For
>backwards compatibility purposes, the point format list extension MAY
>still be included, and contain exactly one value: the uncompressed
>point format (0).  RFC 4492 specified that if this extension is
>missing, it means that only the uncompressed point format is
>supported, so interoperability with implementations that support the
>uncompressed format should work with or without the extension.
>
>
>
> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
> moved to section 2.
>
>
> The content of the last paragraph was moved to a new section:
>
> 2.4.  Algorithms in Certificate Chains
>
>This specification does not impose restrictions on signature schemes
>used anywhere in the certificate chain.  The previous version of this
>document required the signatures to match, but this restriction,
>originating in previous TLS versions is lifted here as it had been in
>RFC 5246.
>
>
>
> 2) In Section 6:
>
>Server implementations SHOULD support all of the following cipher
>suites, and client implementations SHOULD support at least one of
>them:
>
>o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>
> GCM ciphers are not listed in the table earlier in the same section. They
> are defined in RFC 5289. This document doesn't have any reference to RFC
> 5289 and GCM ciphers are not discussed anywhere else in the document.
>
>
> Seems like I missed this one.

Thanks, let me know when the update is ready.

>
> Yoav
>
>



-- 

Best regards,
Kathleen

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

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Kathleen Moriarty]

I haven't approved it yet as I noticed there was no response (that I saw) to 
Alexey's comment and no change in the draft as a result of his comments.

I'll wait in responses for these 2 items.

Thank you,
Kathleen 

Sent from my iPhone

> On May 4, 2017, at 8:41 AM, Hubert Kario  wrote:
> 
>> On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote:
>> All,
>> 
>> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree
>> with Yoav’s statement at the mic in Chicago that the WG should review the
>> changes before we ask Kathleen (our newly appointed AD) to continue
>> progressing the draft.  Please review the differences from the -12 version
>> that went through WGLC and the latest version [0] and let us know by
>> 20170426 whether there is anything that would stop progression of the
>> draft.
> 
> I know I am late with the review, but I'd like to ask two questions:
> 
> 1. In table 2, the "key authorised for use in digital signatures" was 
>removed.
>Does that mean that key usage extension in X.509 certificates should be 
>ignored?
> 2. Given that RFC7919 is already accepted, standards track document, 
>shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in 
>Section 5.5.1.)
> 
> -- 
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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] AD review of draft-ietf-tls-ecdhe-psk-aead-02

[Kathleen Moriarty]

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

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

[Kathleen Moriarty]

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

Re: [TLS] Hugo makes good :)

[Kathleen Moriarty]

Congratulations, Hugo!

Thanks for sharing the news.

On Fri, Apr 14, 2017 at 7:44 AM, Salz, Rich  wrote:
> I know it’s a little off-topic for this list, but this is pretty amazing.
>
>
>
> https://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2017/hugo_m_krawczyk.html
>
>
>
> Wow.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> Member, OpenSSL Dev Team
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

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

Re: [TLS] Uplifting 5289

[kathleen . moriarty . ietf]

Please excuse typos, sent from handheld device 

> On Mar 16, 2017, at 11:37 AM, Yoav Nir  wrote:
> 
> 
>> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
>> 
>> Hi folks
>> 
>> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that 
>> it
>> standardizes some CBC cipher suites, which the WG is looking to move away
>> from. I recognize that these are the only cipher suites you can use in TLS 
>> 1.0
>> and 1.1, but we also want people to move away from them.
>> 
>> This problem is probably solvable by marking the registry as Not 
>> Recommended, but I wondered if anyone had other thoughts on this topic?
>> 
> 
> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch of 
> ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 5246.

TLS 1.2 will be in use for a while unless major problems are found, so it's 
worthwhile IMO.

Kathleen 

> 
> Yoav
> 
> 
> ___
> 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] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

[kathleen . moriarty . ietf]

Please excuse typos, sent from handheld device 

> On Mar 14, 2017, at 6:57 PM, Martin Thomson  wrote:
> 
>> On 15 March 2017 at 09:05, Yoav Nir  wrote:
>>   A secure hash function such as the SHA-256, SHA-384, and SHA-512
>> 
>>   [FIPS.180-4] MUST be used.
> 
> SGTM

The new text is much better, thank you!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-tls-rfc4492bis-15: Yes

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-rfc4492bis/



--
COMMENT:
--

Thanks for your work on this draft.  I just have one question:

In section 5.10, I see the following text:
   The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
   function, such as one of the new SHA hash functions specified in
FIPS
   180-2 [FIPS.180-2], SHOULD be used instead.

Why are you setting the default to SHA-1 and then recommending that
something else should be used?  Why not just start with a different SHA
hash function as the default or at least for TLS 1.2?  I do see the prior
text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended
to go right to TLS 1.2 with the SSLv3 deprecation.  As such, I'm not
clear on why the SHA-1 default.


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

Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

[Kathleen Moriarty]

Thank you for verifying the errata.  I changed the status to verified
after marking it as editorial.

There is another errata on this RFC, 4633.  Is that errata correct?

Best regards,
Kathleen

On Wed, Aug 24, 2016 at 1:31 PM, Xiaoyin Liu <xiaoyi...@outlook.com> wrote:
> Thank you everyone for your explanation! Now I see why it is editorial.
>
>
> Xiaoyin
>
> 
> From: TLS <tls-boun...@ietf.org> on behalf of Bodo Moeller
> <bmoel...@acm.org>
> Sent: Wednesday, August 24, 2016 12:32:50 PM
> To: Watson Ladd
> Cc: he...@florent-tatard.fr; sean+i...@sn3rd.com; Kathleen Moriarty; Chris
> Hawk; Nelson B Bolyard; <tls@ietf.org>; vipul.gu...@sun.com
> Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783)
>
>
>> No, this is wrong. There is a client and there is a server, and
>
>
>> whatever internal arrangements are made are epiphenominal from the
>> perspective of this standard.
>
> They certainly are, but that just means that, in that (unintended) reading
> of the spec, it's using very contrived language to discuss something that's
> not subject to being specified here per se (where more commonly you'd find
> informal language describing the "inner thoughts" of the implantation).
>
>> I doubt anyone was confused by what it
>> said, but either way it needs to get fixed,
>
> Exactly. My point is just that, either way, it can be seen as an editorial
> error rather than a technical one, so there's no need to block the erratum
> on that decision
>
> Bodo



-- 

Best regards,
Kathleen

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

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

[Kathleen Moriarty]

On Thu, Dec 17, 2015 at 10:09 AM, Stephen Farrell
<stephen.farr...@cs.tcd.ie> wrote:
>
>
> On 17/12/15 14:58, Kathleen Moriarty wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-tls-cached-info-20: Yes
>>
>> 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-cached-info/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Just a quick comment, sorry for asking this late and I won't hold up on
>> it either, just want to raise the question without quite enough time to
>> research it all.
>>
>> I see the SHA-256 truncation is just 32 bits.  In other applications,
>> about half is what is typically recommended.  I know you are trying to
>> cut on space, but will problems arise from this shorter value?
>
> Nah, I think this one's ok. IIUC, the result of a collision is
> just a handshake fail, and then presumably recovery when they
> ditch the cached stuff. Section 5 describes this.

OK, no hold up on it, there just wasn't an explanation in the draft as
to why 32 bits was enough in section 5 (or any other).

Thanks,
Kathleen

>
> S.
>
>
>>
>>



-- 

Best regards,
Kathleen

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

[TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-tls-cached-info-20: Yes

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-cached-info/



--
COMMENT:
--

Just a quick comment, sorry for asking this late and I won't hold up on
it either, just want to raise the question without quite enough time to
research it all.

I see the SHA-256 truncation is just 32 bits.  In other applications,
about half is what is typically recommended.  I know you are trying to
cut on space, but will problems arise from this shorter value?


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