Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Judson Wilson]

Inventing your own null cipher security opens up the door for replay,
withhold and reorder styles of attacks.


On Mon, Aug 20, 2018 at 9:20 PM Peter Gutmann 
wrote:

> Lyndon Nerenberg  writes:
>
> >By law, we are forbidden from transmitting encrypted traffic, yet there
> are
> >use cases where integrity protection in the absence of data content
> >protection would be of benefit.
>
> I've worked a lot with a set of authentication-only channels that can't be
> encrypted but need strong integrity/authenticity protection.  The way to
> deal
> with this is signed/MAC'd messages, not NULL-cipher TLS.
>
> 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] EXTERNAL: Re: integrity only ciphersuites

[Judson Wilson]

FWIW HAM might require public key signing rather than MACs, since MACs are
meaningless without a key.


On Mon, Aug 20, 2018 at 5:02 PM Lyndon Nerenberg  wrote:

> There is one other -- admittedly esoteric! -- place where a NULL
> cipher would he useful: Amateur Radio applications.
>
> By law, we are forbidden from transmitting encrypted traffic, yet
> there are use cases where integrity protection in the absence of
> data content protection would be of benefit.
>
> A very common case is controlling a remote repeater site.  Using
> data integrity coupled with a client X.509 certificate means I can
> restrict access to the "control" service at the site.  It's fine
> if people see the traffic in flight, since they won't be able to
> authenticate to do a replay or issue their own commands.
>
> This is a distinct improvement over existing control schemes, which
> typically use DTMF touch tone commands that anyone can trivially
> figure out.
>
> As I said, a very niche case.  It has been done before, using IPsec
> AH, but that's extremely heavy weight, and a pain to configure and
> maintain.  It also requires a full-on IP fabric, whereas TLS can
> be implemented directly on top of AX.25 sessions, which represent
> the vast majority of amateur radio packet data links (which I
> acknowledge puts this outside the realm of the Internet, and therefore
> the IETF).
>
> --lyndon  (VE7TFX)
>
> ___
> 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] integrity only ciphersuites

[Judson Wilson]

How are these devices authenticating?


On Mon, Aug 20, 2018 at 4:14 PM Nancy Cam-Winget (ncamwing)  wrote:

> Hi Eric,
>
> Thanks for the prompt feedback!  Please see further comments/questions
> below:
>
>
>
> *From: *Eric Rescorla 
> *Date: *Monday, August 20, 2018 at 13:58
> *To: *"ncamw...@cisco.com" 
> *Cc: *"tls@ietf.org" 
>
>
> *Subject: *Re: [TLS] integrity only ciphersuites
>
>
>
>
>
>
>
> On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
> ncamwing=40cisco@dmarc.ietf.org> 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.
>
>
>
> Nancy,
>
>
>
> As you say, you don't need WG approval for code point registration as long
> as you don't want Recommended status.
>
>
>
> With that said, I don't think this document makes a very strong case for
> these cipher suites. Essentially you say:
>
>
>
>1. We don't need confidentiality
>
> 2. Code footprint is important
>
>
>
> Generally, I'm not very enthusiastic about argument (1). It's often the
> case that applications superficially need integrity but actually rely on
> confidentiality in some way (the obvious case is that HTTP Cookies are an
> authentication mechanism, but because they are a bearer token, you actually
> need confidentiatilty). It's much easier to just always supply
> confidentiality than to try to reason about when it is or is not needed.
>
> [NCW] We are working diligently in several IoT based consortiums to begin
> to define security around those protocols as many today do not afford any
> protection at all.  At minimum, we want to ensure there is mutual
> authentication and authorization as well as message integrity.  As we cite
> in the draft, many “things” perform repetitive tasks that want to
> communicate motion, speed or other machine control functions that are not
> deemed to be private.
>
> I can see your point/belief that it is much easier to include
> confidentiality, but some chipsets today especially at those levels (and
> cost) are not constructed with those provisions today, though they do have
> HMAC capabilities.
>
>
>
> The second argument is that you are trying to keep code size down. It's
> true that not having AES is cheaper than having AES, but it's possible to
> have very lightweight AES stacks (see for instance:
> https://github.com/01org/tinycrypt).
>
> [NCW] So, it is not just about code size, but overall hardware
> availability and cost….
>
>
>
> So, overall, this doesn't seem very compelling..
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
> Warm regards, Nancy (and Jack)
>
>
> ___
> 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] record layer limits of TLS1.3

[Judson Wilson]

I worry about the buffer sizes required on embedded devices. Hopefully the
other endpoint would be programmed to limit record sizes, but is that
something we want to rely on?  This could be a parameter agreed upon during
the handshake, but that seems bad.


On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos <n...@redhat.com>
wrote:

> On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote:
> > Can you send multiple records in one data transfer to achieve
> > whatever gains are desired?
>
> The packetization cost still remains even if you do that. However, the
> question is how does the 2^14 limit comes from, and why TLS 1.3 should
> keep it?
>
> regards,
> Nikos
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] record layer limits of TLS1.3

[Judson Wilson]

Can you send multiple records in one data transfer to achieve whatever
gains are desired?

On Wed, Nov 23, 2016 at 12:30 AM, Nikos Mavrogiannopoulos 
wrote:

> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote:
> > Hi, Nikos
> >
> > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos 
> > wrote:
> >
> > >
> > > Hi,
> > >  Up to the current draft of TLS1.3 the record layer is restricted
> > > to
> > > sending 2^14 or less. Is the 2^14 number something we want to
> > > preserve?
> > > 16kb used to be a lot, but today if one wants to do fast data
> > > transfers
> > > most likely he would prefer to use larger blocks. Given that the
> > > length
> > > field allows for sizes up to 2^16, shouldn't the draft allow for
> > > 2^16-
> > > 1024 as maximum?
> >
> > I am not opposed to this, but looking at real browsers and servers,
> > we see that they tend to set the size of records to fit IP packets.
>
> IP packets can carry up to 64kb of data. I believe you may be referring
> to ethernet MTU sizes. That to my understanding is a way to reduce
> latency in contrast to cpu costs. An increase to packet size targets
> bandwidth rather than latency (speed).
>
> > The gains from increasing the size of records from the ~1460 bytes
> > that fit in a packet to nearly 64KB are not all that great, and the
> > gains from increasing records from 16 KB to 64KB are almost
> > negligible. At that size the block encryption dominates the CPU time.
>
> Do you have measurements to support that? I'm quite surprized by such a
> general statement because packetization itself is a non-negligible cost
> especially when encryption is fast (i.e., in most modern CPUs with
> dedicated instructions).
>
> regards,
> Nikos
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Judson Wilson]

>
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client
> implementations
> can find other ways to retain long-term records of session keys.  The
> capability
> to do that is not a requisite or desirable protocol feature.  Different
> user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.



I don't believe that storing this information on the endpoints is a great
idea, simply because the monitoring equipment will have a difficult time
ensuring that the information exists when it is needed. It also increases
the number of sites that are risks to compromising past data.

I think this challenge is best solved by putting the information on the
wire in some way, possibly as a special industry-specific extension (used
only by those who are bent on shooting themselves in the foot). The benefit
being that if the TLS channel is alive, the session information is
available to the monitor.  Just as a strawman, the client could transmit
session info in special records, encrypted by a public key, and the
monitoring equipment could scoop these up. For compatibility with servers
outside the network, a middlebox could somehow filter out these records.

It sounds like the need is large enough that such an effort is feasible,
and it would be good to keep normal TLS 1.3 unambiguously forward secure.
(There IS still the question of how to make sure that the extension is not
enabled in endpoints it shouldn't be.)

On Mon, Sep 26, 2016 at 5:20 PM, Viktor Dukhovni 
wrote:

>
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla  wrote:
> >
> > There are other ways to accomplish this.  For example, the server might
> > use session ticket keys that are stored centrally encrypted under a
> > suitable escrow key.  If clients always enable session tickets, then
> > every handshake will result in the server returning a session ticket,
> > in which case the session can be later decrypted if the session ticket
> > keys are available.
> >
> > This actually doesn't work in TLS 1.3 because the resumption master
> secret
> > is not sufficient to decrypt the connection in which it was established.
>
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client
> implementations
> can find other ways to retain long-term records of session keys.  The
> capability
> to do that is not a requisite or desirable protocol feature.  Different
> user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.
>
> --
> Viktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Judson Wilson]

>
> FWIW, I've definitely seen real-world confusion about SSLv3 being a more
> recent protocol than TLS 1.X, by organizations that should know better. If
> there's interest and consensus, this could be a good opportunity to reset
> the situation with TLS/2 or TLS 4.0.
>
> I like TLS/2 aesthetically, and represents a similar level of
> progress/reset that HTTP saw when it jumped from 1.1 to /2.
>
>

What is the slash in the name all about? Is it simply playing off the HTTP
start line specification? Does it have any relevance to TLS?


On Wed, Aug 31, 2016 at 7:01 PM, Eric Mill  wrote:

>
>
> On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes  wrote:
>
>> I am in total agreement with Nick here.  "TLS 1.3" accurately describes
>> what we're doing here, and it's consistent with our past naming scheme.
>>
>> There is no upside to changing away from 1.3, and as Nick notes, lots of
>> potential downside.
>>
>> --Richard
>>
>> On Wednesday, August 31, 2016, Nick Sullivan 
>> wrote:
>>
>>> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
>>> few immediate issues with the proposal:
>>> - it causes confusion with SSL 2.0
>>> - it implies wire incompatibility with TLS 1.2
>>> - it suggests there will be a forthcoming TLS 2.1 with only minor changes
>>>
>>> If we're dead set on bumping the major version for a mostly backwards
>>> compatible protocol change, we should just drop the minor version and go
>>> with TLS/2.
>>>
>>> Nick
>>>
>>
> FWIW, I've definitely seen real-world confusion about SSLv3 being a more
> recent protocol than TLS 1.X, by organizations that should know better. If
> there's interest and consensus, this could be a good opportunity to reset
> the situation with TLS/2 or TLS 4.0.
>
> I like TLS/2 aesthetically, and represents a similar level of
> progress/reset that HTTP saw when it jumped from 1.1 to /2.
>
> -- Eric
>
>
>
>>
>>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>>> wrote:
>>>
 We could call it TLS 3.4 which would match the internal ID. :-)

 BTW, I think using something other than 1.3 is a good idea.

 Cheers - Bill

 
 -
 Bill Frantz| When it comes to the world | Periwinkle
 (408)356-8506  | around us, is there any choice | 16345 Englewood
 Ave
 www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA
 95032

 ___
 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
>>
>>
>
>
> --
> konklone.com | @konklone 
>
> ___
> 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] [Technical Errata Reported] RFC5288 (4694)

[Judson Wilson]

The way I read the first draft, the wording made it sound like "nonce" was
a contraction of the words "(N)umber used (once)". I thought I learned
something. Then I looked it up, and unfortunately, that is not the case, as
cute as it would be.

That is the problem with the wording. Even if a nonce is number that is
only used once, the word is not derived from omitting letters from the
phrase, so we shouldn't mislead people into believing that. Removing the
scare quotes is sufficient to prevent this misunderstanding.

On Sun, May 15, 2016 at 7:23 PM, Joseph Salowey  wrote:

>
> On Sun, May 15, 2016 at 11:43 AM, Rick van Rein 
> wrote:
>
>> Hi,
>>
>> > I think the erratum needs an erratum.  Firstly, "nonce" doesn't mean
>> "number
>> > used once", and secondly nonce re-use in AES-GCM doesn't just result in
>> > "catastrophic failure of it's authenticity", it results in catastrophic
>> > failure of the entire mode, both confidentiality and
>> integrity/authenticity.
>>
>> I'd like to add that I don't see a difference between a "failure" and a
>> "catastrophic failure".  It's probably better to stay away from subjective
>> words like that.
>>
>>
> [Joe] It would be better to state what actually fails:
>
> "Nonce re-use in AES-GCM allows for the recovery of the authentication
> key resulting in complete failure of the mode's authenticity.  Hence, TLS
> sessions can be effectively attacked through forgery by an adversary.
> This enables an attacker to inject data into the TLS allowing for XSS and
> other attack vectors. "
>
>
>
>> -Rick
>>
>
>
> ___
> 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] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field

[Judson Wilson]

Hello folks,

We'd like to add a field to the KeyUpdate message that represents the
generation of receive traffic keys in use by the sender of the KeyUpdate
message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426)

How this helps: In the current draft, an endpoint that sends a KeyUpdate
message and later receives a KeyUpdate message cannot know whether the
other side has actually updated its receive keys. The two messages may have
been generated independently and crossed in flight. Putting a
receive_generation field in the KeyUpdate message lets an endpoint confirm
that the other side has received and acted upon an earlier KeyUpdate
message.

Why we want this: We've been researching how to restrict corporate
middleboxes like intrusion-detection systems and virus scanners. Today,
these scanners generally demand man-in-the-middle access to TLS traffic and
require users to install a private root CA. We think it would be better if
they only had "read-only" access and didn't MITM the traffic.

One way for a client to grant delayed read-only access in TLS 1.3 is with a
"rotate and release." The client starts by sending a KeyUpdate. Later,
after all traffic keys from the previous generation have been superseded on
both sides, the client releases the (superseded) traffic keys to the
middlebox. The middlebox can use the keys to decrypt the previous
generation of ciphertext, without danger of compromising the integrity of
the session. The challenge is that an endpoint can't safely release its old
send keys until it knows that the other side has updated its receive keys.
Hence the receive_generation field.

We think this is a pretty lightweight way to resolve the ambiguity from
KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or
extra rounds or messages. Thanks in advance for any feedback.

Sincerely,
Judson Wilson (+ Henry Corrigan-Gibbs, Riad S. Wahby
 Keith Winstein, Philip Levis, and Dan Boneh)
Stanford University
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls