Subject: [Lurk] BoF scope: protocols

From: Yaron Sheffer <[email-masked]>
Date: Mon, 8 Feb 2016 21:49:20 +0200

Hi,

To clarify the scope of the BoF, we might want to edit the proposal
[1] somewhat. The first few sentences are kind of general, and talk
about TLS, IPsec and SSH. So far, nobody came up with a use case
that relates to IPsec or SSH. I would like to suggest that we make
the BoF proposal more concrete and specific by mentioning only TLS.
Something like:

Old

Communication protocols like IPsec, SSH or TLS provide means to
authenticate the remote peer. Authentication is based on the proof
of ownership of a private key.

New

The TLS protocol in typical use authenticates the server by proving
ownership of a private key, which is associated with a public-key
certificate. [And then replace "peer" by "server" in subsequent
sentences.]

Opinions?

Thanks,

Yaron

[1] https://trac.tools.ietf.org/bof/trac/wiki#Security

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Feb 2016 22:06:52 +0200

Hi, Yaron

> On 8 Feb 2016, at 9:49 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi,
> 
> To clarify the scope of the BoF, we might want to edit the proposal [1] somewhat. The first few sentences are kind of general, and talk about TLS, IPsec and SSH. So far, nobody came up with a use case that relates to IPsec or SSH. I would like to suggest that we make the BoF proposal more concrete and specific by mentioning only TLS. Something like:
> 
> Old
> 
> Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based on the proof of ownership of a private key. 
> 
> New
> 
> The TLS protocol in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. [And then replace "peer" by "server" in subsequent sentences.]
> 
> Opinions?

I’d narrow it down even further. This is not about any protocol protected with TLS. This is pretty much only HTTPS.

HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate.  [you’d still replace subsequent “peer”s with “server”s or even “web servers”]

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Feb 2016 20:43:23 +0000

> I’d narrow it down even further. This is not about any protocol protected with TLS. This is pretty much only HTTPS.

I think this is a good simplification for starting off.

An SSH use case I can think of has role-based keys securely maintained and individuals speak off-host to that server in order to ssh to a deployed machine.  For example. :)

---

From: Eric Burger <[email-masked]>
Date: Mon, 8 Feb 2016 19:33:28 -0500

> An SSH use case I can think of has role-based keys securely maintained and individuals speak off-host to that server in order to ssh to a deployed machine.  For example. :)

A theoretical example or a real one?

---

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Feb 2016 14:16:02 +0000

Hi Yaron,

Restricting to TLS only seems to me too restrictive. I suggest we extend it to TLS/DTLS. On the other hand, we may restrict the scope to some TLS/DTLS versions. Maybe the scope may be reduced to versions 1.2 and 1.3.

I would then propose the following text:

The TLS/DTLS protocols in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. [And then replace "peer" by "server" in subsequent sentences.]

BR,
Daniel
From: Lurk [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, February 08, 2016 3:07 PM
To: Yaron Sheffer
Cc: LURK BoF
Subject: Re: [Lurk] BoF scope: protocols

Hi, Yaron

On 8 Feb 2016, at 9:49 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Old

New

Opinions?

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 9 Feb 2016 15:44:13 +0000

> > An SSH use case I can think of has role-based keys securely maintained and
> individuals speak off-host to that server in order to ssh to a deployed
> machine.  For example. :)
> 

Yes :)

But FWIW I support limiting to TLS keys in HTTPS for now.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Feb 2016 19:54:10 +0000

Hiya,

On 08/02/16 19:49, Yaron Sheffer wrote:
> Hi,
> 
> To clarify the scope of the BoF, we might want to edit the proposal [1] 
> somewhat. The first few sentences are kind of general, and talk about TLS, IPsec 
> and SSH. So far, nobody came up with a use case that relates to IPsec or SSH. I 
> would like to suggest that we make the BoF proposal more concrete and specific 
> by mentioning only TLS. Something like:
> 
> Old
> 
> Communication protocols like IPsec, SSH or TLS provide means to authenticate the 
> remote peer. Authentication is based on the proof of ownership of a private key.
> 
> New
> 
> The TLS protocol in typical use authenticates the server by proving ownership of 
> a private key, which is associated with a public-key certificate. [And then 
> replace "peer" by "server" in subsequent sentences.]
> 
> Opinions?

With no hat, I think the New text is maybe a better plan, but since
I just hit the issue again a moment ago, I'd like to just ask about
a different possible use-case:

Would there be any support for including within scope support for PGP
and/or S/MIME decryption/signing operations?

This would be to tackle the problem of using multiple MUAs whilst only
wanting one key pair that one doesn't want to "install" on a bunch of
hosts. (Nice niche concern eh - can anyone find a niche-ier niche? :-)

I think the answer is likely "no" and even if it were "yes" and a
whole bunch of folks wanted to work on that, (which I doubt) and
even if people would implement and deploy (I'd be surprised if we
got significant instances of either), it might be better if it were
handled quite differently to HTTPS or TLS. But I did want to ask
so that a conclusion gets in the archive. (And a total lack of
response is a valid way to reach the obvious conclusion in this case
I reckon.)

Cheers,
S.

> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 9 Feb 2016 21:55:12 +0200

On 02/09/2016 04:16 PM, Daniel Migault wrote:
>
> Hi Yaron,
>
> Restricting to TLS only seems to me too restrictive. I suggest we 
> extend it to TLS/DTLS. On the other hand, we may restrict the scope to 
> some TLS/DTLS versions. Maybe the scope may be reduced to versions 1.2 
> and 1.3.
>
> The TLS/DTLS protocols in typical use authenticates the server by 
> proving ownership of a private key, which is associated with a 
> public-key certificate. [And then replace "peer" by "server" in 
> subsequent sentences.]
>
> BR,
>
> Daniel
>
>
If we want to include DTLS, I would suggest that we look a use case that 
justifies it. Unless I'm missing something, there are no CDNs that 
distribute content via DTLS.

Thanks,
     Yaron

---

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Feb 2016 21:04:14 +0000

Hi Yaron,

I am not aware either of CDNs using UDP, but as UDP is a transport layer that get more and more attraction,  I would prefer not to explicitly exclude DTLS.

BR,
Daniel

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Tuesday, February 09, 2016 2:55 PM
To: Daniel Migault; Yoav Nir
Cc: LURK BoF
Subject: Re: [Lurk] BoF scope: protocols

Hi Yaron,

BR,
Daniel

If we want to include DTLS, I would suggest that we look a use case that justifies it. Unless I'm missing something, there are no CDNs that distribute content via DTLS.

Thanks,
    Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Feb 2016 23:05:56 +0200

More specifically, if QUIC (or SPUD) takes off, CDNs might support it.

But I think anything we do here would be trivially adaptable to such a world. I don’t think we should be jumping the gun just yet.

Yoav

> On 9 Feb 2016, at 11:04 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi Yaron,
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 9 Feb 2016 21:07:00 +0000

> More specifically, if QUIC (or SPUD) takes off, CDNs might support it.

Akamai's announced support for QUIC, but it currently does not use DTLS.  The announced plans are to use TLS 1.3 handshake, but not the record format which means still not DTLS.